一、MySQL Redis常用部署方式1.1 拓扑1.2 特点业务层通过双写同时写MySQL及Redis。读通常在Redis，若读取不到，则从MySQL读取，然后将数据同步到Redis，Redis通常设置expire或者默认LRU进行数据淘汰。 这种使用方式会有如下问题： 1）MySQL及Redis存在数据不一致风险，尤其是长时间运行的系统 2）业务层需要处理MySQL sql schema与Redis kv数据结构上的逻辑差异 3）无统一运维 4）无法方便扩容/缩容 二、KV化的存储使用理念2.1 MySQL Is great NoSQL参考文档： http://www.aviransplace.com/2015/08/12/Mysql-is-a-great-nosql/ 为什么要用MySQL: “在可扩展系统构建时，一个很重要的考量是使用的技术是否成熟，选择成熟的技术意味着出错时能够迅速恢复。当然，开发者也可以在项目中使用最新最牛的NoSQL数据库，而这个数据库在理论上也可以良好地运行，然而在生产环境中出现了问题恢复需要多久？技术上已有的知识和经验积累对于问题缓解至关重要，当然这个积累也包括了Google可以搜索到的内容。 相比之下，关系型数据库已经存在了超过四十年，业界对于关系型数据库的维护也积累了大量的经验。基于这些考虑，在新项目做技术选型时通常会选择Mysql，而不是NoSQL数据库，除非NoSQL真的有非常非常明显的优势。” 2.2 KV理念对于亿级规模的数据存储，尤其是涉及到水平拆分跨机分库分表的情况下，线上对数据库的访问只能做的越简单越好，group by/order by/分页/通用join/事务等等的支持 在这个量级下的MySQL系统都是不合适的。 基本上目前所有的类proxy的MySQL方案真正上规模线上应用只能使用按拆分键进行读写操作，实际上也是一个用拆分键做的一个kv系统。 若想使用复杂的sql处理，最合理的部署方案是将Mysqlbinlog流水同步服务抽象出来，通过实时同步到OLAP类的系统进行处理。 所以面向海量存储服务，MySQL从一开始就设计为一个KV系统是可行的。value使用mediumblob存储xml/json/protobuf/thrift格式化数据序列化之后的数据。 2.3 MySQL KV化的使用方式1、用MySQL原来的主键或者索引键当做key 2、其他所有的非主键非索引键，全部包装到value里面，value使用mediumblob存储xml/json/protobuf/thrift格式化数据序列化之后的数据。 3、数据读写操作，均基于key一整行数据做读写，由业务层对里面value的结构做解析及对内部结构做增删改差，而不用变更MySQL本身的schema. 2.4 不适用场景1、数据量和访问量不大并且业务逻辑依赖MySQL数据库进行处理的业务场景 2、涉及到多表join等的处理 对于此限制，也可以通过将关联表加工成基于关联条件的一张宽表进行KV化。 3、涉及到事务等的处理。
三、将MySQL Redis设计为统一的KV存储服务3.1目标1）业务层通过统一方式访问MySQL及Redis，不再使用MySQL客户端及Redis客户端访问 2）MySQL集群化/Redis集群化部署 3）将业务双写改为MySQL到Redis底层binlog数据同步方式完成同步 4）异构数据存储支持最终一致性数据读写服务 5）支持存储层面扩容缩容、failover且业务无感知 6）单机群日百亿次QPS/TPS支持（大类业务适度拆分到不同集群中） 3.2最终实现基于MySQL Redis的统一存储服务（UniStore） = MySQL跨机分库分表集群 Redis集群 MySQL- |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
