分布式系统和数据同步要点

1，基础缓存更新应该采用Databus实时同步，Solr采用cancel等工具实时同步，非基础数据采用业务层做同步。

2，redis失效用户请求会压倒DB如何处理，A设置不同的过期时间 B对有些数据设置永不过期 C考虑服务降级 D二级缓存本地缓存。

3，写库失败，第二部淘汰缓存失败，出现数据不一致，如果先淘汰缓存再DB失败，则会引发cache miss，肯定是先淘汰缓存再写DB，加入1个服务层，向下游屏蔽底层数据存储细节，DB每次更新binlog，读取日志到rsync0update异步更新到cache，或者非主流方案，所有写数据走DB，所有读数据走cache，用异步工具做DB和cache同步。有1个init初始化全缓存过程。

4，读高可用的方法：复制从库，冗余数据。双主同步key冲突，引发不一致，由DB、业务层保证key在2个主上不冲突，双主当主从用，不做读写分离，主挂掉切换到另外一个主上，索引会降低写性能，不同的库可以建立不同的索引，主库只提供写，不建立索引，增加从库会影响一致性，引入服务层屏蔽数据库和缓存访问，中间件将key上的写路由到主，在一定时间范围内（主从同步完成的窗口时间），该key上的读也路由到主，发生写请求，先淘汰缓存，再写数据库，额外增加1个timer，主从同步完成时间后再淘汰。

5，MQ异步解耦，通知变更后调用接口获取数据，更新cache时同步调用服务，后异步更新缓存，数据多出来源并发调用聚合，异步请求做合并，1次调用能拿到所有数据。订单消息如每次变更，相关查询结算、库存系统均订阅，分布式DB接入层对应server拓扑信息需要调整，订阅后将变更的拓扑信息下发到每个客户端备用。顺序消费，DB binlog基于MQ进行复制，消费者可以更新ElasticSearch，也可以修改Redis，基于日志重放同步数据到一个全量DB中，多个消费分区，每个索引分区只可以顺序消费，多个连续区间消费后在合并。

6，当DB（监听从库），binlog有变化，cancel监听到时候解析过滤发送MQ（表名字，主键等）到变化的实时从库中查询数据同步到ES聚合表，MQ可以重试，系统解耦。事务log挖掘县城会对DB的事务log监听，并把这些事件发布到消息代理。

7，MQ做数据同步也会造成不一致，又需要引入监控，实时计算2个集群的数据同步，做一致性同步。大部分来说，同步es和solr不要在代码中去同步，同步失败无法保证事务，而且业务耦合。可以使用Databug和cancel等工具去做代码解耦，MQ支持重试，存储失败后抛出异常下次再处理。数据做异构，对外服务时任意拼装，MYSQL在半同步复制上做了一些优化，保证了一致性，引入了诸如paxos等主流算法保证强一致性问题。

8，主从同步上 A方案：主等从同步完成，写主库请求才返回，吞吐量降低   B方案：读写都在主库上  C方案：中间件，记录所有写库写的key，在主从同步时间窗口（500ms），有读请求访问中间件则将key路由到主库，但是中间件成本高  D方案：某个key要写，记录在redis中，超时时间为500ms。

9，过大秒的商品data和状态data，活动的配置和状态，系统级数据：集群地址，mq初始长度、cpu连接数等，对于http和middle节点，采用pull拉方式拉取监控数据，大规模时采用间隔时间可以降低到2s，其他如管理平台可以利用agent周期性push到redis队列，dcucenter采集协调程序实时从redis拉取，如果push需要保障所有agent存活，不稳定因素很大。同步商品仓储实时库存到秒杀系统，秒杀系统可以有双库存保障，1个是实时的，1个是虚拟也就是资格号，只有2个都有货时才可以正常销售。

10，主Data中心北京M，成都A，上海B，A增加1条记录，发送MQ到M和B，B增加1条记录也发送MQ到M，M把增加的记录发给AB，AB找到自己缺乏的数据，更新数据库，A发到M，接收到M的应答就删除消息，MQ不是很靠谱。

11，一个机房生成的data会用程序异步分发到其他机房，业务层数据分发选择需要分发的数据，A机房读不到数据，则到B/C机房去读，通过接口而不是数据库访问。一个手机号只能注册一个账号，A中心数据宕机未同步到B，让用户到B重新注册，B无法判断该手机号码是否重复注册；AB在异常情况下都修改了用户信息，如何处理冲突，一种是按照时间进行合并，最后修改的生效，但是异地服务器时间无法同步。还有一种生成全局唯一递增ID，而这种全局ID系统也要考虑异地多活。日活千万，每天注册可能几万，修改信息1万，登录1千万对于新用户注册来说并不明显影响，修改影响也不是很大，而如果百万用户登录不上影响很大，ABCD均有所有用户的信息，用户在哪个中心均可以登录，A宕机则到B登录，减少距离，同城多机房多中心，也必须有1个其他城市的备份业务中心，减少数据同步如session
token等，重新login，A机房注册1个用户，要求5分钟内同步到所有机房即可，异常甚至可以到1天，当然5分钟后B机房没有这个用户信息需要根据路由规则到A机房请求数据，避免只是使用存储系统同步功能，多种手段，MQ二次读取，回源读取，A登录回去A拿session ID。

12，实现防缓存雪崩的lock，限流进来，慢慢初始化数据，每隔几分钟离线更新下页面缓存。mongodb保存在内存中，重启就不在了，可以做实时监控，每天100万数据以内，时间作为索引顺序读写，mongodb做索引非常丰富，支持地理索引，淘宝三个月前的数据迁移到hdfs中。

13，搜索更新同步分为增量和全量更新，增量更新商品组发送MQ到搜索进行更新，10到30分钟可搜索到。全量更新时每天都会对搜索的数据库重新建立索引，保证在数据库中的数据更新，凌晨6点离线开始生成，再推送到线上，时间较长，第二天9点钱PC，列表，app等更新完成。

14，消费MQ时，可以将msg存入阻塞queue如syncQueue或ArrayBlockQueue等（注意防止队列撑爆，ArrayBlockQueue需要设置数量，并使用put函数，put会阻塞），多线程消费这个Queue，可以一定程度上防止MQ消息堆积。