异地多活关键点梳理

l异地多活的本质, 其实就是分库分表(ldc逻辑机房和普通机房的区别).

不过会多出来一些概念, 有些数据不在一个库了. 例如订单按照用户去分库, 然后需要查询商家的数据.

还不够 星际系统 ,商家的1对多商品价格延迟,1对1改价延迟? 

 

这个时候就有了新的概念, 商家的数据需要同步,同步到不同的城市,即CZone ( 支付宝架构到底有多牛逼！没看完我就跪了！ )

 

哪些业务适合最初的异地多活.

     下单这种,每次都是新增的. 而且请求量最大,最核心的业务.

     附属于订单的表和业务适合迁移.(只管理一个订单) 帐户这种不是附属关系.(订单使用了帐户,被多个订单关联)

 

    多活不代表同一份数据可以在多地更新.

 

1、专访阿里巴巴毕玄：异地多活数据中心项目的来龙去脉 

http://www.infoq.com/cn/articles/interview-alibaba-bixuan

同城双活与异地多活架构分析 https://www.jianshu.com/p/3f925c039fe8  有uid route代码

 

  

2、

http://virtualadc.blog.51cto.com/3027116/624466
http://chongit.github.io/2015/04/15/GSLB%E6%A6%82%E8%A6%81%E5%92%8C%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86/
http://www.infoq.com/cn/articles/how-weibo-do-unit-architecture
http://timyang.net/architecture/cell-distributed-system/
https://yq.aliyun.com/articles/2350
http://h2ex.com/524
http://www.cnblogs.com/dkblog/p/5046001.html
http://os.51cto.com/art/201601/503525.htm

 

1. 一期 下单相关流程数据库单点. 附属于订单的.(只管理一个订单) 帐户这种不是附属关系.(订单使用了帐户,被多个订单关联)

    自增 redis 单点.

    长连接.

    缓存同步 (不然瞬间击穿)

   

2. 订单域数据库多活

     对应的 id 生成器是不是单元化的,多活的? 自增区间不一样.

    

3. 第三期 支付和用户这块多活.

    一个 accountId,在哪里是乱序的. 有个关系表. 可以把关系表变成范围的,这样.

    关系表就可以异地多活了.  但是做不了单元化.

    那又何必呢,每一次都有这个性能损耗? 而且这个数据的读取是用来判断去哪里更新的. 所以又不能去读缓存,会存在数据不一致的问题. 更新频率低,那么可以通过加读写锁来实现. 这样的话,又要去读一个锁有没有锁住. 这个锁可以放在单元化里么? 答案好像时不能.

   所以还不如 帐户不做单元化,不和发单单元化. 通过范围分区. 如果一个单元挂了. 将这部分数据 hash 到各处去. 避免流量集中上升.