大数据量下mysql实践.pptVIP

大数据mysql实践 杨青 2015.7.18 内容 如何保证数据库可用性？ 解决思路--数据冗余（复制） 如何提高数据库读性能？ 三种方式提高读性能 如何保证数据一致性？ 主从一致性、数据库与缓存一致性 数据库如何扩展？ n库变2n库、增加字段、数据库迁移 数据库拆库四中场景 单key、1对多、多对多、单key 分库后业务的查询 如何保证数据库可用性？ 可用性，数据冗余（复制） 1，保证“读”高可用的方法： 复制从库，冗余数据，如图： 带来的问题：主从数据不一致，主从延迟 解决方案：a) 忽略错误后，继续同步 b) 重新做主从，完全同步 2，保证“写”高可用方法： 双主模式，即复制主库，冗余数据，如图： 带来的问题：双主同步key冲突，引发数据不一致 解决方案： a）方案一：由业务层保证key在两个主上不冲突 b）方案二：数据库自增id奇偶数 3，双主当主从用，不做读写分离，在主库挂掉的情况下，从库当主库顶上，如图： 优点：读写都到主，解决了一致性问题；双主当主从用，解决了可用性问题 带来的问题：如何提高读性能？ 如何提高数据库读性能？ 一，建立索引 建立非常多的索引，副作用是： a）降低了写性能 b）内存空间有限，索引占用大量内存，其内存中数据减少，查询数据命中率降低，查询时扫描磁盘，IO增多； 但是否想到，不同的库可以建立不同的索引呢？如图 不同的库可以建立不同索引，主库只提供写，不建立索引 二，增加从库 这种方法会引发主从不一致问题，从库越多，主从时延越长，数据不一致问题越严重 解决办法：如上所述 如何提高数据库读性能？ 三，增加缓存 传统缓存的用法是： a）写请求时，先淘汰缓存，再写数据库； b）读请求时，先读缓存，缓存命中则返回，失败则读数据库并将数据入缓存； 带来的问题： a）所有业务层都要关注缓存，“主从”数据不一致，造成缓存脏数据问题； b）数据复制引发一致性问题，由于主从延时的存在，可能引发缓存与数据库数据不一致； 解决思路： a）增加服务端缓存，如图 好处是： 1）引入服务层屏蔽“数据库+缓存” 2）不做读写分离，读写都到主的模式，不会引发不一致 b）不做读写分离，读写都到主的模式，不会引发不一致 如何保证数据一致性？ 一，主从不一致解决方案 方案一：引入中间件，如图 中间件将写数据路由到主，在一定时间范围内（主从同步完成），该数据上的读也路由到主； 方案二：读写都到主，不做读写分离，不会不一致，如图 二，数据库与缓存不一致解决方案：两次淘汰 异常数据的读写，导致旧数据写入缓存，一次淘汰不够，要进行二次淘汰 a）写请求时，先淘汰缓存，再写数据库，额外增加一个定时机制，一定时间（主从同步完成）后再次淘汰； b）读请求时，先读缓存，命中返回，失败则读数据库并将数据入缓存（此时可能旧数据入缓存，但会被二次淘汰淘汰掉，最终不会引发不一致） 数据库扩展--数据库n库变2n库？ 需求：原来N个库，现在要扩充为2N个库，希望不影响服务，快速完成数据库扩展 最开始，分为2个库，分别0库和1库，均采用“双主当主从用”的模式保证可用性，如图： 接下来，将从库提升主库，并修改服务端配置，快速完成数据库扩库，由于是2扩4，不会存在数据迁移，原来的0库变为0库+2库，原来的1库变为1库和3库，如图： 最后，解除旧的双主同步（0库和2库不会数据冲突），为了保证可用性增加新的双主同步，并删除掉多余的数据 这种方案可以秒级完成N库到2N库的扩容。 存在的问题：只能完成N库扩2N库的扩容（不需要数据迁移），非通用扩容方案（例如3库扩4库就无法完成） 扩展后均采用“双主当主从用”的模式，如图： 数据库扩展--增加字段、数据迁移、增加索引 一，追日志方案 a）记录写日志 b）倒库 c）倒库完毕 d）追日志 e）追日志完毕