海量读请求架构

需求

在很多的场景，比如某个核心服务，如热门视频或者实时排名等等，都存在大量读的场景。架构上通用的做法是读写服务分离，写服务部署少量，有存储写入瓶颈，读服务一般可以水平扩展

无热点key

写： mysql + redis
读：redis

有热点key

写： mysql + redis + etcd
读：redis + etcd + 本地缓存

那么本地缓存如何更新呢？简单的做法是设置本地超时时间，但是这样会带来数据的不一致，因为多个读进程的本地缓存副本数据不一致。轮询+超时的策略是很low的，可以利用etcd实现读进程watch语义，读进程watch 数据的变更。

写进程

更新缓存，更新mysql，更新etcd： key，/hot_data/id， value：version,注意不要用timestamp，避免时钟不一致，mysql db设计最好加一个版本号。etcd只保存id和version这样的元数据。

读进程

系统起来的时候从/hot_data/*读取所有的热点id，然后读取redis里面的数据，构建本地缓存。然后watch etcd /hot_data/，从上次读取到的版本号watch，可以保证不漏过任何更新事件，当watch到etcd变更的时候，重读redis更新本地缓存。

性能

有人可能会怀疑读进程太多了会拖垮etcd，理论上可能。只要热点id不是很多，更新不频繁，etcd支撑1w个watch是没有压力的，假设读进程有1w个，每个读进程可以handle 10w qps，那么总qps就是10亿。如果确实有性能问题，可以使用etcd镜像，由多个镜像来分担watch压力，还是可以水平扩展并且对读进程透明。

后续

很多文章和架构都介绍的由读进程去维护redis缓存，缓存位于读进程和redis之间的旁路或者主路，其实都是不合理的，一来是容易导致惊群问题，二是容易缓存穿透，这都给读进程提供了很多负担，另外要么会有进程之间的缓存不一致或者热点key问题。。。听说阿里开源了一个工具可以监听mysql的binlog来更新缓存，挺高大上，但是依然没有解决热点key的问题，如果不使用进程级别的缓存，只能把热点key增加多个名字以分散读压力，认为减轻热点问题。我觉得都挺low，还是把写数据和更新数据交给写进程，读进程负责读数据以及watch变更。