本文根据陈永庭老师在〖DAMS 2017中国数据资产管理峰会〗现场演讲内容整理而成。
(点击底部“阅读原文”获取陈永庭演讲完整PPT)
讲师介绍
陈永庭,饿了么框架工具部高级架构师,主要负责MySQL异地双向数据复制,支撑饿了么异地多活项目。曾就职于WebEx、Cisco、腾讯等公司。
今天我主要分享饿了么多活的底层数据实施,会和大家介绍在整个多活的设计和实施过程中我们是怎么处理异地数据同步的,而这个数据同步组件在我们公司内部称之为DRC。
异地多活背景
在讲DRC或者讲数据复制之前,先跟大家回顾一下异地多活的背景。
去年我们在做多活调研的时候,整个公司所有的业务服务都是部署在北京机房,服务器大概有四千多台,灾备的机器是在云端,都是虚拟机,大概有三千多台。当时我们峰值的业务订单数量已经接近了千万级别,但是基本上北京机房(IDC)已经无法再扩容了,也就是说我们没有空余的机架,没有办法添加新的服务器了,必须要再建一个新的机房,于是我们在上海建一个新的机房,上海机房要在今年的4月份才会投入使用,所以需要在上海机房建成之后,异地多活项目能具备在生产环境上进行灰度。
异地多活的底层数据同步实施
这是异地多活的底层数据同步实施的一个简单的概要图,大家可以看到,我们有两个机房,一个是北京机房,一个是上海机房。在这个时候,我们期望目标是北方所有的用户请求、用户流量全部进入北京机房,南方所有的用户请求、用户流量进入上海机房。困难的地方是,这个用户有可能今天在北方,明天在南方,因为他在出差,还有就是存在一些区域在我们划分南北shard的时候,它是在边界上面的,这种情况会加剧同一个用户流量在南北机房来回漂移的
一般是做异地备份和异地容灾。目前也有更好的选择,比如说用“多备份”这款工具来实现异地多云备份容灾,把MySQL数据库加密分布式存储备份到百度云、阿里云、亚马逊云、金山云、腾讯云、七牛、ucloud等,保证数据不丢失原则上MySQL是不支持多主一从的复制架构的,有一个思路可以考虑,就是采用在从机上用多个MySQL实例来实现,不过,也要看你的各个主数据库数据量的大小,对从机服务器IO的影响等等因素。总体来说,还是要看你的应用想解决什么问题,只有仔细分析你的应用系统的实际需求,才能设计出适合的方案欢迎分享,转载请注明来源:内存溢出
评论列表(0条)