<p>摘要：本文介绍基于MySQL及Redis搭建统一的kv存储服务：常用部署方式及其特点，Cluster manager，MySQL和Redis集群方案，以及Sync数据同步服务。</p>    <p>秦波，8年开发及架构经验， 之前在华为/京东/小米参与部分核心基础服务的设计与开发工作，目前在九州证券负责大数据平台及风控相关项目的技术研发工作。 关注高并发/高可靠/服务监控与治理/分布式存储/大数据相关系统的架构和实现。</p>    <h2><strong>一、MySQL+Redis </strong> <strong> 常用部署方式 </strong></h2>    <h2>1.1  拓扑</h2>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/f56c00ff6a186387d7a7d5d0e8eb1348.png"></p>    <h2>1.2  特点</h2>    <p>业务层通过双写同时写MySQL及Redis。读通常在Redis，若读取不到，则从MySQL读取，然后将数据同步到Redis，Redis通常设置expire或者默认LRU进行数据淘汰。</p>    <p>这种使用方式会有如下问题：</p>    <p>1）MySQL及Redis存在数据不一致风险，尤其是长时间运行的系统</p>    <p>2）业务层需要处理MySQL sql schema与Redis kv数据结构上的逻辑差异</p>    <p>3）无统一运维</p>    <p>4）无法方便扩容/缩容</p>    <h2><strong>二、KV</strong> <strong>化的存储使用理念</strong></h2>    <h2>2.1  MySQL Is great NoSQL</h2>    <p>参考文档：</p>    <p>http://www.aviransplace.com/2015/08/12/Mysql-is-a-great-nosql/</p>    <p>为什么要用MySQL:</p>    <p>“在可扩展系统构建时，一个很重要的考量是使用的技术是否成熟，选择成熟的技术意味着出错时能够迅速恢复。当然，开发者也可以在项目中使用最新最牛的NoSQL数据库，而这个数据库在理论上也可以良好地运行，然而在生产环境中出现了问题恢复需要多久？技术上已有的知识和经验积累对于问题缓解至关重要，当然这个积累也包括了Google可以搜索到的内容。</p>    <p>相比之下，关系型数据库已经存在了超过四十年，业界对于关系型数据库的维护也积累了大量的经验。基于这些考虑，在新项目做技术选型时通常会选择Mysql，而不是NoSQL数据库，除非NoSQL真的有非常非常明显的优势。”</p>    <h2>2.2  KV理念</h2>    <p>对于亿级规模的数据存储，尤其是涉及到水平拆分跨机分库分表的情况下，线上对数据库的访问只能做的越简单越好，group by/order by/分页/通用join/事务等等的支持 在这个量级下的MySQL系统都是不合适的。</p>    <p>基本上目前所有的类proxy的MySQL方案真正上规模线上应用只能使用按拆分键进行读写操作，实际上也是一个用拆分键做的一个kv系统。</p>    <p>若想使用复杂的sql处理，最合理的部署方案是将Mysqlbinlog流水同步服务抽象出来，通过实时同步到OLAP类的系统进行处理。</p>    <p>所以面向海量存储服务，MySQL从一开始就设计为一个KV系统是可行的。value使用mediumblob存储xml/json/protobuf/thrift格式化数据序列化之后的数据。</p>    <h2>2.3  MySQL KV化的使用方式</h2>    <p>1、用MySQL原来的主键或者索引键当做key</p>    <p>2、其他所有的非主键非索引键，全部包装到value里面，value使用mediumblob存储xml/json/protobuf/thrift格式化数据序列化之后的数据。</p>    <p>3、数据读写操作，均基于key一整行数据做读写，由业务层对里面value的结构做解析及对内部结构做增删改差，而不用变更 MySQL 本身的schema.</p>    <h2>2.4  不适用场景</h2>    <p>1、数据量和访问量不大并且业务逻辑依赖 MySQL 数据库进行处理的业务场景</p>    <p>2、涉及到多表join等的处理</p>    <p>对于此限制，也可以通过将关联表加工成基于关联条件的一张宽表进行KV化。</p>    <p>3、涉及到事务等的处理。</p>    <h2><strong>三、将MySQL+Redis设计为统一的KV存储服务</strong></h2>    <h2>3.1  目标</h2>    <p>1）业务层通过统一方式访问MySQL及Redis，不再使用MySQL客户端及Redis客户端访问</p>    <p>2）MySQL集群化/Redis集群化部署</p>    <p>3）将业务双写改为MySQL到Redis底层binlog数据同步方式完成同步</p>    <p>4）异构数据存储支持最终一致性数据读写服务</p>    <p>5）支持存储层面扩容缩容、failover且业务无感知</p>    <p>6）单机群日百亿次QPS/TPS支持（大类业务适度拆分到不同集群中）</p>    <h2>3.2  最终实现</h2>    <p>基于MySQL+Redis的统一存储服务（UniStore） =</p>    <p>MySQL跨机分库分表集群</p>    <p>+ Redis集群</p>    <p>+ MySQL->Redis实时数据同步服务</p>    <p>+ 统一的对外数据访问接口</p>    <p>+ 内在的完整运维支持系统（支持在线扩容/缩容、failover等）</p>    <h2>3.3  架构图</h2>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/30a81741c476f6f15e925c97f44bceb1.jpg"></p>    <h2>3.4  架构说明-将存储设计为一种服务</h2>    <p>1、将MySQL+Redis做成统一KV存储服务</p>    <p>2、通过acc proxy提供统一的数据访问接口，通过统一协议支持跨语言数据访问</p>    <p>访问协议（自定义协议，protobuf协议，thrift协议等）</p>    <p>3、MySQL cluster支持跨机的分库分表，schemaless设计，所有业务表KV化设计</p>    <p>4、Redis cluster支持跨机的实例拆分</p>    <p>5、Sync数据同步服务提供统一的Mysql到Redis 跨IDC/不跨IDC数据同步服务，小于100ms延时</p>    <p>6、整个系统不涉及到分布式事务处理</p>    <h2>3.5  三种部署方式</h2>    <p>1、纯MySQL集群部署</p>    <p>此种部署方式等同于其他MySQL proxy跨机分库分表方案，读写均在MySQL</p>    <p>2、纯Redis集群部署</p>    <p>此种部署方式等同于其他Redis proxy跨机分库分表方案，读写均在Redis</p>    <p>3、MySQL+Redis异构部署</p>    <p>写在MySQL，读可以从MySQL读或者Redis读，取决于业务对最新数据的读取要求。</p>    <h2>3.6  接口说明</h2>    <p>1、int get(int appid, string key,string& value)</p>    <p>Redis读操作专用</p>    <p>2、int get_with_version(int appid,string key, string& value, int64& version)</p>    <p>MySQL 读操作专用，自带版本号，防止写覆盖</p>    <p>3、int set(int appid, string key,string value, int64 version)</p>    <p>通过appid区分 MySQL 还是Redis，均支持写操作</p>    <p>4、int delete(int appid, string key)</p>    <p>通过appid区分 MySQL 还是Redis, 不支持批量删除</p>    <p>5、int multiget(int appid,vector<string> keys, map<string, string>& key_value_pairs)</p>    <p>支持批量读操作，内部的数据路由及数据合并不用关心</p>    <p>6、intmultiset(int appid, map<string, string>& key_value_pairs)</p>    <p>不建议支持，涉及到跨机事务问题，无法保证ACID</p>    <p>7、int Redis_op(string cmd, ……)</p>    <p>Redis其他原生接口封装(incr/expire/list/setnx等)</p>    <h2><strong>四、Cluster Manager服务</strong></h2>    <h2><strong>4.1  Cluster Manager</strong> <strong>是一个service</strong></h2>    <p>cluster manager主要由如下几种功能</p>    <p>1）MySQL/Redis分片路由信息的管理</p>    <p>1、 MySQL 分库分表路由信息</p>    <p>2、Redis Slot路由信息</p>    <p>3、路由信息变更管理</p>    <p>2）Redis实例的探活及Redis扩容及缩容数据的迁移</p>    <p>比如连续3次，每次间隔30sRedis ping失败，认为实例挂掉，发出报警或者自动切换</p>    <p>3）Cluster manager不建议参与Mysql group主备层面的管理</p>    <p>MySQL 主备层面的集群管理方案：</p>    <p>1、MHA+VIP （互联网公司最常用）</p>    <p>2、微信phxsql系统：https://github.com/tencent-wechat/phxsql   金融级可靠性</p>    <h2><strong>五、</strong> <strong>MySQL</strong> <strong>集群方案</strong></h2>    <h2>5.1  架构图</h2>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/21838444bd1eb552af893dbf9b8d0a2f.jpg"></p>    <h2>5.2  设计原则</h2>    <p>1）统一的schemaless表结构</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/bc37d3b7f0bc9bbcd4c37ac852362c30.png"></p>    <p>2）跨机的数据分布</p>    <p>支持将单逻辑表水平拆分到多个Mysql服务器中</p>    <p>3）其他说明</p>    <p>1、数据存储可靠性高，所有业务数据通过序列化存储到value列</p>    <p>2、每行数据自带版本号，业务通过cas方式防止业务层多实例同时写造成写覆盖</p>    <p>全局唯一版本号实现：本机微秒时间戳+server_id+proccess_id</p>    <p>3、固定百库百表/百库十表的数据拆分方式，多机跨Mysql实例部署</p>    <h2>5.3  路由策略</h2>    <h2>1) 一致性hash</h2>    <p style="text-align:center"><img src="https://simg.open-open.com/show/983d5291c361b3b0a9b9505a00b82fd9.jpg"></p>    <p>2) 路由计算算法</p>    <p>crc32/md5/基于字符串的各类hash算法</p>    <p>3) 路由信息格式</p>    <p>CREATETABLE `Mysql_shard_info` (</p>    <p>`appid` int(32) NOT NULL,</p>    <p>`begin` int(32) NOT NULL,</p>    <p>`end` int(32) NOT NULL,</p>    <p>`ip` varchar(20) NOT NULL DEFAULT '',</p>    <p>`port` int(11) NOT NULL DEFAULT '0',</p>    <p>`user` varchar(50) NOT NULL DEFAULT '',</p>    <p>`pwd` varchar(50) NOT NULL DEFAULT '',</p>    <p>PRIMARY KEY (`appid`,`begin`)</p>    <p>)ENGINE=InnoDB DEFAULT CHARSET=utf8;</p>    <h2>5.4  数据迁移/自动扩展</h2>    <p>数据迁移:</p>    <p>STEP1：利用 MySQL 主备复制机制进行数据复制</p>    <p>STEP2：数据差异小于某一临界值，停止老分片写操作（read-only）</p>    <p>STEP3：等待新分片数据更新完毕</p>    <p>STEP4：更路由规则路由规则，Cluster Manager向所有access proxy更新路由信息</p>    <p>STEP5：删除老分片</p>    <p>自动扩展:</p>    <p>过程类似于数据迁移</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/21c1b5b780857602d441748c268d18f1.png"></p>    <p><strong>六、Redis</strong> <strong> 集群方案 </strong></p>    <h2>6.1  部署方式</h2>    <p>1、异构读写分离-MySQL写，Redis读</p>    <p>1) 数据写操作在 MySQL ，读操作在Redis</p>    <p>2) 数据通过Sync系统对binlog进行解析从Mysql同步到Redis</p>    <p>3) 数据有同步延迟（小于100ms），实现最终一致性</p>    <p>适用场景：要求数据高可靠，且读量比较大，允许读数据短时间不一致，若期望一直读到最新数据，请使用get_with_version()接口从 MySQL 读取</p>    <p>2、独立的Redis集群服务</p>    <p>1）读写均在Redis，提供独立的KV存储服务</p>    <p>2) 用户不用关注扩容/缩容/故障恢复等问题</p>    <p>3) 集群内多业务混存，提高内存的使用率</p>    <p>适用场景：独立的Redis集群服务，类似twenproxy/codis</p>    <h2>6.2  设计要点</h2>    <p>1、一致性hash</p>    <p>支持数据跨Redis实例拆分，固定Slot数进行拆分</p>    <p>2、单机多实例部署</p>    <p>1）每个物理机支持多Redis实例</p>    <p>2）每个Redis实例只服务单个业务</p>    <p>3）Redis实例内存大小取决于业务需求，同时考虑业务访问量和数据量</p>    <p>以RedisIP+port标示唯一实例，对于128G内存机器，</p>    <p>可配置3 Redis实例*每实例30G</p>    <p>或10 Redis实例*每实例10G</p>    <p>或20 Redis实例*每实例5G</p>    <p>拆分原则：单实例最大内存使用 < 本机剩余内存</p>    <p>3、以Slot为单位的平滑扩容/缩容</p>    <p>4、以Redis实例为单位的failover处理</p>    <h2>6.3  平滑扩容/缩容</h2>    <p>主要步骤如下：</p>    <p>STEP1:确认扩容/缩容</p>    <p>Cluster manager通过对系统负载和数据量进行告警，进而确认进行扩容或者缩容</p>    <p>STEP2:修改路由表</p>    <p>1)修改路由表，将对应shard的状态修改为migrate状态，并将新路由推送到所有接入层</p>    <p>2)acc proxy会将写操作转到新的Redis实例中，读操作默认先读新Redis实例，key不存在会继续从老的Redis实例中读取</p>    <p>STEP3:数据迁移</p>    <p>1）Cluster manager通过自动数据迁移工具开始数据迁移，计划依赖Redis的scan命令将相关的key扫出来，通过MIGRATE进行数据迁移</p>    <p>2）多次扫描执行该过程，确认Slot中所有数据迁移完成</p>    <p>STEP4:修改路由表，迁移完成</p>    <p>Cluster manager将读写均切到新Redis实例，不再从老Redis中进行操作</p>    <h2><strong>七、</strong> <strong>Sync</strong> <strong>数据同步服务</strong></h2>    <h2>7.1  架构</h2>    <p style="text-align:center"><img src="https://simg.open-open.com/show/1fd349003cb4e82873bc96b9507b5bae.png"></p>    <p>7.2  应用场景</p>    <p>该服务完全可以抽象成独立的数据同步分发服务，对于因为KV化而丢失的sql处理完全可以通过该服务同步到偏OLAP类的系统中进行处理。除了同步到Redis还可以同步到ElasticSearch或者hbase或者写hdfs文件基于hadoop生态去实现复杂计算和分析。</p>    <h2>7.3  设计要点</h2>    <p>1、集群对集群的实时数据同步</p>    <p>MySQL 统一要求binlog日志为row格式</p>    <p>2、不涉及DDL处理</p>    <p>由于 MySQL schemaless的设计，不用考虑DDL处理，简化同步服务（跨/不跨IDC）</p>    <p>3、基于时间戳的同步延迟监控</p>    <p>MySQL binlog row格式日志自带时间戳，基于此时间戳进行同步延迟监控</p>    <p>4、基于binlog文件名+offset的同步位置管理</p>    <p>定时定量持久化保存当前同步的binlog文件名及offset,用于各种场景下的同步恢复</p>    <p>5、基于行的并行同步</p>    <p>多线程同步模式，主线程通过对tableid或者key做hash,将binlogevent时间分发到对应worker线程的队列中，worker线程依次从队列中获取binlog event执行</p>    <h2>7.4  实现原理</h2>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/9a5e29defd487e28a1bc90217c8d8b7d.jpg"></p>    <p>原理相对比较简单：</p>    <p>1）Sync同步工具模拟Mysql slave的交互协议，伪装自己为 MySQL slave，向Mysqlmaster发送dump协议</p>    <p>2）Mysqlmaster收到dump请求，开始推送binary log给slave(也就是同步工具)</p>    <p>3）Sync同步工具解析binary log对象(原始为byte流)，并转换成Redis或其他存储（hdfs/hbase/ES等数据库）相应数据操作接口或者作为消息存储到MQ中（rocketmq或者kafka）</p>    <h2><strong>7.5  ROW</strong> <strong>格式events</strong></h2>    <p>MySQL 5.5 Binlog的事件类型有多种，这里只介绍与ROW模式相关的事件</p>    <p>1) QUERY_EVENT：与STATEMENT模式处理相同，存储的是SQL，主要是一些与数据无关的操作，eg: begin、drop table</p>    <p>2) TABLE_MAP_EVENT：记录了下一条事件所对应的表信息，在其中存储了数据库名和表名</p>    <p>3) WRITE_ROWS_EVENT：操作类型为insert</p>    <p>4) UPDATE_ROWS_EVENT：操作类型为update</p>    <p>5) DELETE_ROWS_EVENT：操作类型为delete</p>    <p>6) XID_EVENT， 用于标识事务提交(commit)</p>    <p>典型的insert语句有如下4个events组成：</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/4b458c368d5ce8efe633dd377d6c89b8.jpg"></p>    <h2>7.6  其他开源同步方案</h2>    <p>1. tungsten-replicator(JAVA)</p>    <p>http://code.google.com/p/tungsten-replicator/</p>    <p>2. linkedin  databus(JAVA)</p>    <p>https://github.com/linkedin/databus</p>    <p>3. Alibaba  canal(JAVA)</p>    <p>https://github.com/alibaba/canal /</p>    <p> </p>    <p> </p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s/I_bOF5WKuTZr9PAAevY_lw</p>    <p> </p>