一次线上小问题的思考

    tn-零售平台事业部-底层研发部-A组    

    今天&＃xff0c;技术经理让我处理一个问题&＃xff1a;app首页的产品列表&＃xff0c;第9个&＃xff0c;第11个&＃xff0c;两个产品一模一样。

    先讲一下项目的架构&＃xff1a;

    注&＃xff1a;每个箭头都有相反方向的对应箭头&＃xff0c;我懒&＃xff0c;不画了。

    portal负责app首页、频道页的大部分服务端功能&＃xff0c;主要用于聚合信息&＃xff0c;cms是中间层&＃xff0c;调用搜索&＃xff0c;获取产品信息。ror是搜索项目&＃xff0c;具体处理请求&＃xff0c;通过solr获取数据。portal&＃xff0c;cms我都做过一部分&＃xff0c;ror没做过&＃xff0c;具体细节不清楚&＃xff0c;只知道是操作solr的。

    一个请求的处理过程是这样:APP send a request to portal, and portal query data from cache(redis) firstly, if get something from cache, send response to app, if not, send request to cms, then get data from cms. When cms get a request from portal, it query data from cache, if get nothing,  send a request to ror and get data from it.  m站有自己的服务端&＃xff0c;是php的。php也是先查缓存&＃xff0c; 再查portal。

      可以看出&＃xff0c;这是多个微服务组成的系统&＃xff0c;各个应用间通过restful方式相互调用。好处是解耦&＃xff0c;坏处是重复造轮子&＃xff0c;资源利用率不高&＃xff0c;前前后后多少个缓存&＃xff1f;

        在谈谈我是怎么解决技术经理的问题的。首先&＃xff0c;app是分页&＃xff0c;每页10条&＃xff0c;向portal请求产品列表的&＃xff0c;第一页的第9个&＃xff0c;第二页的第1个&＃xff0c;两个产品完全一样&＃xff01;我看了看m站&＃xff0c;没有出现问题&＃xff0c;有可能php的缓存把它保护了。再看看cms&＃xff0c;先是 cms不走缓存&＃xff0c;发现app相同的产品排在第11个(第2页第一个)&＃xff0c;然后cms走缓存&＃xff0c;app相同的产品排在第9个。于是&＃xff0c;我大概知道原因了。portal缓存了第1页的老数据&＃xff0c;缓存了第2页的新数据。我删了portal的产品列表的缓存&＃xff0c;问题解决了。

        我告诉经理解决了&＃xff0c;问题的原因是缓存不一致&＃xff0c;方案是删缓存。经理让我想想有没有更好的方法。我想了想&＃xff0c;将思考写入此文。

        首先&＃xff0c;缓存不一致&＃xff0c;是因为前前后后有很多缓存&＃xff0c;每个缓存的存活时间是1小时。所以会出现缓存不一致的问题&＃xff0c;这本质上是分布式一致性的问题。(那就有了分布式锁&＃xff0c;分布式一致性)。

        那么&＃xff0c;就有两种思路&＃xff1a;1&＃xff0c;能不能只有一套缓存&＃xff0c;portal&＃xff0c;cms共用一套缓存。(我只能管到这两个项目&＃xff0c;其他的我也不知道&＃xff0c;也管不了&＃xff0c;也没有权限操作)那就不存在缓存不一致了。2&＃xff0c;可以保留多套缓存&＃xff0c;但能不能提供  缓存更新通知 缓存同步\异步刷新&＃xff1f;

        思路一&＃xff1a;

        思路一是简单粗暴的&＃xff0c;还节省了缓存服务器&＃xff0c;真省钱。前面提到&＃xff0c;我们是微服务&＃xff0c;各应用间通过restful接口实现调用&＃xff0c;这种方式有好处——业务逻辑封装在应用内部&＃xff0c;外部调用方不可见(高内聚)&＃xff0c;A系统出了问题&＃xff0c;不会太多的影响B系统(低耦合)。坏处是每次调用需要一次http链接&＃xff0c;建立链接是耗时的&＃xff0c;还存在网络故障、延时的风险&＃xff0c;所以每个应用自己有一套缓存&＃xff0c;避免每次都要调接口&＃xff0c;提升性能(所以就有了缓存不一致问题&＃xff0c;即——分布式一致性问题&＃xff0c;关于分布式cap&＃xff0c;详见http://www.cnblogs.com/bangerlee/p/5328888.html)。那么如何做到只有一套缓存呢&＃xff1f;见下图&＃xff1a;

        如图所示&＃xff0c;大概都画清楚了。四个黄条分表代表  过滤器-控制器-业务层-数据层。图中&＃xff0c;缓存放在了dao之后&＃xff0c;其实&＃xff0c;也可以放在filter-controller之间&＃xff0c;controller-business之间&＃xff0c;business-dao之间。

        先讲dao之后。他要保证的核心&＃xff0c;是确保&＃xff1a;只有cms能往缓存写数据&＃xff0c;portal&＃xff0c;以及其他任何应用&＃xff0c;都没有写权限&＃xff01;你能想象&＃xff0c;cms刚写完&＃xff0c;portal就把它改了&＃xff0c;删了吗&＃xff1f;另外&＃xff0c;由于现在用的是redis&＃xff0c;是单线程操作的&＃xff0c;不用过多考虑并发场景下的异常情况&＃xff0c;memcache等多线程操作的cache就复杂了。除了保证&＃xff0c;缓存只有cms能写&＃xff0c;还要考虑portal从缓存没有读到数据的情形。是缓存过期了&＃xff1f;还是缓存里本来就不该存在这次请求对应的数据&＃xff1f;针对这个问题&＃xff0c;有两种思路:
        1 没有获取到缓存时&＃xff0c;直接调用cms的restful接口&＃xff0c;cms本身不读缓存(portal就没读到&＃xff0c;cms就没必要读了)&＃xff0c;而是直接从后台获取数据&＃xff0c;如果有&＃xff0c;返回给portal&＃xff0c;可以在返回给portal之前&＃xff0c;同步/异步写到缓存里。如果并发量大&＃xff0c;可以使用redis setnx语句&＃xff0c;避免多次写同一个key,也可以将写任务提交到任务队列&＃xff0c;提高性能。如果cms没有从后台获取到数据&＃xff0c;最好返回一个无害的默认值(降级)&＃xff0c;并设置缓存&＃xff0c;记录请求的上下文到日志&＃xff0c;便于日后分析。为什么呢&＃xff1f;防止缓存击穿。假设有这样一个流程&＃xff1a;恶意用户用一个恶意入参请求portal&＃xff0c;portal从缓存没有取到数据&＃xff0c;调用cms&＃xff0c;cms调用ror&＃xff0c;也没取到&＃xff0c;也没设一个默认值到缓存&＃xff0c;就返回了。这样&＃xff0c;恶意用户重复这个流程100万次&＃xff0c;portal会取100万次缓存&＃xff0c;调100万次cms&＃xff0c;调100万次ror&＃xff0c;ror调100万次solr&＃xff0c;这会产生灾难性的后果&＃xff01;如果在缓存设个默认值&＃xff0c;时间不用长&＃xff0c;5分钟&＃xff0c;30分钟&＃xff0c;避免缓存击穿造成的严重后果。(时间不能长&＃xff0c;是因为可能存入大量无害的默认信息&＃xff0c;失效时间长了&＃xff0c;影响缓存的容量以及性能。另外&＃xff0c;恶意用户短时间内发现恶意请求不起破坏性效果&＃xff0c;就极有可能换个恶意请求了)。当然&＃xff0c;也可以采用防刷、限流的方式&＃xff0c;熔断、降级&＃xff0c;甚至封号&＃xff0c;加黑名单。。。

        2 portal始终只从缓存读&＃xff0c;没读到就直接返回null或无害的默认值。这就要cms保证缓存的完整性、及时性、有效性。cms必须将全量的数据存入缓存(只有这样&＃xff0c;才满足portal只从缓存取数据的基本条件)。缓存时间可以为永久&＃xff0c;或者短时间缓存。如果缓存时间短&＃xff0c;如1h&＃xff0c;则可以做个定时任务&＃xff0c;如半小时&＃xff0c;定时更新全量的缓存&＃xff0c;要保证半小时更新完所有缓存&＃xff0c;这只能尽量保证数据的及时性&＃xff0c;有效性。如果缓存永久&＃xff0c;必须有一个通信机制&＃xff0c;让cms知道要更新哪些数据&＃xff0c;如mq等。另外&＃xff0c;更新缓存要考虑数据备份&＃xff0c;防止因为异常&＃xff0c;导致缓存出问题。

     缓存也可放在filter-controller之间&＃xff0c;这里离用户最近&＃xff0c;性能也最好。但这就相当于把business层处理完的数据存入了cache&＃xff0c;这违反了只有cms有写权限的原则&＃xff01;解决方法是将portal&＃xff0c;cms两个项目合并。但这就不是微服务了。缓存放在其他地方也是同理。

        以上是一套缓存的分析&＃xff0c;下面分析多套缓存的方案。

        多套缓存&＃xff0c;即保持现有架构不变。那就要解决多个缓存之间的不一致问题——本质上是分布式一致性的问题。关于分布式cap&＃xff0c;详见http://www.cnblogs.com/bangerlee/p/5328888.html。当cms缓存失效、更新时&＃xff0c;通过消息机制jms通知portal删除或跟新缓存&＃xff0c;这是异步的。如果对一致性要求不极致&＃xff0c;这样就可以了&＃xff0c;改造成本也小&＃xff0c;加个mq就行了(如果要求更低&＃xff0c;什么都不用改&＃xff0c;等缓存自己失效&＃xff0c;现在就是这样的)。如果要求强一致性&＃xff0c;就要引入分布式事务&＃xff0c;可以基于mysql&＃xff0c;redis&＃xff0c;或者zookeeper。个人建议基于curator&＃xff0c;采用  分布式锁&＃43;分布式事务, http://ifeve.com/zookeeper-leader/    http://curator.apache.org/    http://zookeeper.apache.org