哪些业务适合最初的异地多活.
下单这种,每次都是新增的. 而且请求量最大,最核心的业务.
附属于订单的表和业务适合迁移.(只管理一个订单) 帐户这种不是附属关系.(订单使用了帐户,被多个订单关联)
多活不代表同一份数据可以在多地更新.
1、专访阿里巴巴毕玄：异地多活数据中心项目的来龙去脉
http://www.infoq.com/cn/articles/interview-alibaba-bixuan
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 到各处去. 避免流量集中上升.