一篇文了解分布式队列编程：从模型、实战到优化(3)

采集计费系统架构图如下：

• 用户点击浏览收集服务(Click/View Collector)作为生产者部署在多个机房里,以提高收集服务可用性.

• 每个机房里采集到的数据通过消息队列中间件发送到核心机房IDC_Master.

• Billing服务作为消费者部署在核心机房集中计费.

采用此架构,我们可以在如下方面做进一步优化：

• 提高可扩展性,如果一个Billing部署实例在性能上无法满足要求,可以对采集的数据进行主题分区(Topic Partition)计费,即采用发布订阅模式以提高可扩展性(Scalability).

• 全局排重和反作弊.采用集中计费架构解决了点击浏览排重的问题,另一方面,这也给反作弊提供了全局信息.
• 提高计费系统的可用性.采用下文单例服务优化策略,在保障计费系统集中性的同时,提高计费系统可用性.

分布式缓存更新(Distributed Cache Replacement)

缓存是一个非常宽泛的概念,几乎存在于系统各个层级.典型的缓存访问流程如下：

• 接收到请求后,先读取缓存,如果命中则返回结果.

• 如果缓存不命中,读取DB或其它持久层服务,更新缓存并返回结果.

对于已经存入缓存的数据,其更新时机和更新频率是一个经典问题,即缓存更新机制(Cache Replacement Algorithms ).典型的缓存更新机制包括：近期最少使用算法(LRU)、最不经常使用算法(LFU).

这两种缓存更新机制的典型实现是：启动一个后台进程,定期清理最近没有使用的,或者在一段时间内最少使用的数据.由于存在缓存驱逐机制,当一个请求在没有命中缓存时,业务层需要从持久层中获取信息并更新缓存,提高一致性.

挑战

分布式缓存给缓存更新机制带来了新的问题：

• 数据一致性低.分布式缓存中键值数量巨大,从而导致LRU或者LFU算法更新周期很长.在分布式缓存中,拿LRU算法举例,其典型做法是为每个Key值设置一个生存时间(TTL),生存时间到期后将该键值从缓存中驱逐除去.考虑到分布式缓存中庞大的键值数量,生存时间往往会设置的比较长,这就导致缓存和持久层数据不一致时间很长.如果生存时间设置过短,大量请求无法命中缓存被迫读取持久层,系统响应时间会急剧恶化.
• 新数据不可用.在很多场景下,由于分布式缓存和持久层的访问性能相差太大,在缓存不命中的情况下,一些应用层服务不会尝试读取持久层,而直接返回空结果.漫长的缓存更新周期意味着新数据的可用性就被牺牲了.从统计的角度来讲,新键值需要等待半个更新周期才会可用.

构思

根据上面的分析,分布式缓存需要解决的问题是：在保证读取性能的前提下,尽可能地提高老数据的一致性和新数据的可用性.如果仍然假定最近被访问的键值最有可能被再次访问(这是LRU或者LFU成立的前提),键值每次被访问后触发一次异步更新就是提高可用性和一致性最早的时机.

无论是高性能要求还是业务解耦都要求缓存读取和缓存更新分开,所以我们应该构建一个单独的集中的缓存更新服务.集中进行缓存更新的另外一个好处来自于频率控制.

由于在一段时间内,很多类型访问键值的数量满足高斯分布,短时间内重复对同一个键值进行更新Cache并不会带来明显的好处,甚至造成缓存性能的下降.通过控制同一键值的更新频率可以大大缓解该问题,同时有利于提高整体数据的一致性,参见“排重优化”.

综上所述,业务访问方需要把请求键值快速传输给缓存更新方,它们之间不关心对方的业务.要快速、高性能地实现大量请求键值消息的传输,高性能分布式消息中间件就是一个可选项.这三方一起组成了一个典型的分布式队列编程模型.

架构

如下图,所有的业务请求方作为生产者,在返回业务代码处理之前将请求键值写入高性能队列.Cache Updater作为消费者从队列中读取请求键值,将持久层中数据更新到缓存中.

采用此架构,如果一个Cache Updater在性能上无法满足要求,可以对键值进行主题分区(Topic Partition)进行并行缓存更新,即采用发布订阅模式以提高可扩展性(Scalability).

后台任务处理

（编辑：ASP站长网）