数据库秒级平滑扩容架构方案要领.pdfVIP

数据库秒级平滑扩容架构⽅案 ⼀、缘起 （1）并发量⼤，流量⼤的互联⽹架构，⼀般来说，数据库上层都有⼀个服务层，服 务层记录了“ 务库名”与“数据库实例”的映射关系，通过数据库连接池向数据库路由 sql语句以执⾏： 如上图：服务层配置⽤户库user对应的数据库实例物理位置为ip （其实是⼀个内⽹域 名）。 （2 ）随着数据量的增⼤，数据要进⾏⽔平切分，分库后将数据分布到不同的数据库 实例 （甚⾄物理机器）上，以达到降低数据量，增强性能的扩容⽬的： 如上图：⽤户库user分布在两个实例上，ip0和ip 1，服务层通过⽤户标识uid取模的⽅ 式进⾏寻库路由，模2余0 的访问ip0上的user库，模2余1的访问ip 1上的user库。 关于数据库⽔平切分，垂直切分的更多细节，详见 《⼀分钟掌握数据库垂直拆分》。 （3 ）互联⽹架构需要保证数据库⾼可⽤，常见的⼀种⽅式，使⽤双主同步 +keepalived+虚ip 的⽅式保证数据库的可⽤性： 如上图：两个相互同步的主库使⽤相同的虚ip 。 如上图：当主库挂掉的时候，虚ip ⾃动漂移到另⼀个主库，整个 程对调⽤⽅透明， 通过这种⽅式保证数据库的⾼可⽤。 关于⾼可⽤的更多细节，详见 《究竟啥才是互联⽹架构“⾼可⽤”》。 （4 ）综合上⽂的 （2 ）和 （3 ），线上实际的架构，既有⽔平切分，又有⾼可⽤保 证，所以实际的数据库架构是这样的： 提问：如果数据量持续增⼤，分2个库性能扛不住了，该怎么办呢？ 回答：继续⽔平拆分，拆成更多的库，降低单库数据量，增加库主库实例 （机器）数 量，提⾼性能。 最终问题抛出：分成x个库后，随着数据量的增加，要增加到y个库，数据库扩容的过 程中，能否平滑，持续对外提供服务，保证服务的可⽤性，是本⽂要讨论的问题。 ⼆、停服务⽅案 在讨论平滑⽅案之前，先简要说明下“x库拆y库”停服务的⽅案： （1）站点挂⼀个公告“为了为⼴⼤⽤户提供更好的服务，本站点/游戏将在今晚00:00- 2:00之间升级，届时将不能登录，⽤户周知” （2 ）停服务 （3 ）新建y个库，做好⾼可⽤ （4 ）数据迁移，重新分布，写⼀个数据迁移程序，从x个库⾥导⼊到y个库⾥，路由 规则由%x升级为%y （5 ）修改服务配置，原来x⾏配置升级为y⾏ （6 ）重启服务，连接新库重新对外提供服务 整个过程中，最耗时的是第四步数据迁移。 回滚⽅案： 如果数据迁移失败，或者迁移后测试失败，则将配置改回x库，恢复服务，改天再挂 公告。 ⽅案优点：简单 ⽅案缺点： （1）停服务，不⾼可⽤ （2 ）技术同学压⼒⼤，所有⼯作要在规定时间内做完，根据经验，压⼒越⼤约容易 出错 （这⼀点很致命） （3 ）如果有问题第⼀时间没检查出来，启动了服务，运⾏⼀段时间后再发现有问 题，难以回滚，需要回档，可能会丢失⼀部分数据 有没有更平滑的⽅案呢？ 三、秒级、平滑、帅⽓⽅案 再次看⼀眼扩容前的架构，分两个库，假设每个库1亿数据量，如何平滑扩容，增加 实例数，降低单库数据量呢？三个简单步骤搞定。 （1）修改配置 主要修改两处： a ）数据库实例所在的机器做双虚ip ，原来%2=0 的库是虚ip0 ，现在增加⼀个虚 ip00 ，%2= 1的另⼀个库同理 b ）修改服务的配置 （不管是在配置⽂件⾥，还是在配置中⼼），将2个库的数据库配 置，改为4个库的数据库配置，修改的时候要注意旧库与⾟苦的映射关系： %2=0 的库，会变为%4=0与%4=2 ； %2= 1的部分，会变为%4= 1与%4=3 ； 这样修改是为了保证，拆分后依然能够路由到正确的数据。 （2）reload配置，实例扩容 服务层rel ad配置，rel ad可能是这么⼏种⽅式： a ）⽐较原始的，重启服务，读新的配置⽂件 b ）⾼级⼀点的，配置中⼼给服务发信号，重读配置⽂件，重新初始化数据库连接池 不管哪种⽅式，rel ad之后，数据库的实例扩容就完成了，原来是2个数据库实例提供 服务，现在变为4个数据库实例提供服务，这个过程⼀般可以在秒级完成。 整个过程可以逐步重启，对服务的正确性和可⽤性完全没有影响： a ）即使%2寻库和%4寻库同时存在，也不影响数据的正确性，因为此时仍然是双主数 据同步的 b ）服务rel ad之前是不对外提供服务的，冗余的服务能够保证⾼可⽤ 完成了实例的扩展，会发现每个数据库的数据量依然没有下降，所以第三个步骤还要 做⼀些收尾⼯作。 （3