应用场景
笔者遇到这样的一个场景：网站大概有10万用户，应用属于网址中的一个新模块，要记录对服务调用的行为轨迹，比如，用户A在什么时间，调用了什么方法，传入的参数是什么。设计一高稳定性，种高性能，低复杂度的解决方法。
分层设计
自底向上分层，大概有这样的层次。
第一、持久层设计。目前，在大型互联网应用中，主流的持久化方式有两种：基于关系型数据库的分库分表；基于列式数据库的大数据存储，Hbase或者MangoDB。在这个层次上，笔者使用的是HBase，这个选择是的原因在与，日志记录以写入为主，日志记录完成之后，是要对这些大量的数据进行分析，统计，这样的场景天然就适合Hadoop的HBase，它具备高写入性能，还有就是可以用MapReduce的方式对海量的行为日志进行挖掘分析与统计。
HBase适用场景：
关系型手库分库分表适用场景：
第二、缓冲容器，用来缓冲用户的行为模型，后台任务消费这个缓冲容器中的实体对象，实体对象是无状态的。容器选择的比较丰富，但是差别却很大。从最简单的数组，带高可靠性的消息队列。要基于这样的前提进行选择：必须是并发容器，因为用户访问是并发的，日志记录也必须是并发的；高容量，假设有1万个用户同时使用该模块，不会发生内存溢出；高吞吐量，这样持久化的时候就可以进行批量插入，提升持久化性能。
LinkList适用场景：
Redis轻量级队列适用场景：
MQ队列适用场景：
第三、IO方式。最简单的方式，在用户线程中同步记录日志，如果使用这种方式，缓冲容器就不需要了，直接调用持久化服务，搞定。但是，同步的方式增加了用户的响应时间，所以，应该使用异步的方式，也就是说，在用户线程中收集了日志信息之后，将信息模型丢入缓冲容器，由后台任务消费日志信息。后台任务的设计也有两种方式可以选择，一，单线程消费缓冲容器的日志信息；二，由一个boss线程轮询缓冲容器，当日志信息达到一定量，假设这个量是1000，在超过1000的时候，boss线程唤醒worker线程池中的线程，由work线程进行批量消费。
同步方式适用场景：
异步方式适用场景：
第四、服务层切入。这里，笔者使用的是Spring AOP 方式，切入服务方法，在服务方法调用前，构建一个日志信息模型，再下一层处理日志信息模型。
方案分析
方案一、同步记录日志。
方案二、异步BlockingQueue。
方案三、异步轻量级队列。
方案四、异步消息队列。
方案五、异步批处理。
适用性评估
数量级。
可靠性要求。
暂无评论
写评论