跨服务经常使用散布式缓存的三个思索 性能优化

最近遇到的几个名目区分用到了本地环境和散布式缓存。关于各种类型，咱们宿愿做成设计标杆，不论是业务团队同窗自己开发还是咱们架构团队协助优化，都有一套规范的设计模版。

本文是经常使用Redis散布式缓存优化的名目。

要不要冲破服务化的限度

过后拿到需求的时刻有个纠结点：原来数据查问服务经过RPC调用数据存储服务，由于触及RPC调用以及查数据库，耗时长。所以宿愿咱们加一层缓存，绝大少数状况下间接从Redis取数据。如下图所示：

通常的设计要做服务化，一个服务对外提供增删改查，而缓存这种优化应该放到服务外部。也就是说数据查问服务查问依然须要经过API来调用数据存储服务，存储服务做不做缓存，数据查问服务应该是不感知的。如下图所示。

而需求方的原始需求会破环服务的封装性。这个矛盾怎么来处置呢？可以这样来思索。作为一个服务，外部的数据处置，包含存储、逻辑处置这些是要封装在外部的。然而可以经常使用战略形式提供灵敏的访问API。RPC调用是一种访问形式，redis调用是另外一种访问形式。这样就不算破坏封装行。如下图所示：

数据分歧性校验算不算多余？

这个和需求方探讨没有达成分歧。这也是为什么我延续三天都发文了。我不想破坏文章内容在实践实施时原本的先后顺序，但这一篇要赶在技术评审之前收回来，作为跟需求方探讨的一个资料。

这个设计Redis和MySQL里数据各存储了一份，既然有异构的存储， 架构团队这边以为数据分歧性校验是要做的。而需求方以为既然都是消费MQ信息后处置，假设处置的没有疑问就不会出现数据不分歧的疑问。所以只需有个手动运维补救机制来处置消费缺点即可，没有必要定时巡检来做数据分歧性校验。

我不时听从的理念是关于担任的服务或许配置，要做到：可观测、可权衡、可应答。自己开发的配置模块是正确的，怎么权衡呢？

数据分歧性审核就是用来权衡正确性的。假设逻辑没有破绽，数据分歧性审核应该每次巡检对比数据都是分歧的。一旦出现不分歧，就是逻辑上出疑问了，都是须要case by case剖析并做逻辑的修正或许补充的。

假设逻辑原本就便捷，跑了一年都没有审核出任何的数据不分歧，这个审核是不是糜费呢？服务和配置都是要演进的，要做变卦。变卦要做到可灰度、可监控、可应急。数据分歧性审核就是监控变卦后逻辑正确性的手腕。

总结来说：这个数据分歧性校验属于业务巡检的一项，是用来发现疑问的。发现疑问可以经过在设计、开发阶段做严厉的设计审查、代码Review来防止一局部。经过逻辑来保障能否属于 适度设计？需求方对这个逻辑究竟有哪些顾忌呢？

巡检逻辑会不会参与业务的复杂性、对数据库形成额外的压力？

这个巡检逻辑咱们计划经过散布式调度义务来做。经过散布式调度平台，可以手动触发口头义务作为上线时初始化数据的手腕，同时也是缺点处置的应急预案，原本就是要做的，做成巡检只是每天定时口头一次性，不会参与业务的复杂性。

对数据库的压力方面，这个巡检确实须要扫描数据库。然而咱们会经过控制分页，驳回>id，应用索引等手腕来优化深度分页，并且会经过观察消费监控筛选低峰期口头，由于这是读数据，不会加互斥锁，表的数据量也不大，估量对数据库的压力可以疏忽不计。

我自己在沟经环节中犯了一个很重大的失误。在论证数据分歧性巡检有必要做的时刻，我说：「业界都是这么做的。」我之前确实是调研过各个做的比拟好的大厂，他们关于业务巡检都十分注重。然而我的表白犯了在《批评性思想》这本书中引见的「笃信威望」的失误。

更正确的处置形式是要从：长处、劣势、必要性、老本等角度来思索。更要被动征询需求方的顾忌。