数据库架构(转)

Posted 2020-11-01 酒醉三分醒

1. 业界难题-“跨库分页”的四种方案

    1). 方法一：全局视野法

         a.将order by time offset X limit Y，改写成order by time offset 0 limit X+Y

         b.服务层对得到的N*(X+Y)条数据进行内存排序，内存排序后再取偏移量X后的Y条记录

         这种方法随着翻页的进行，性能越来越低。

     2). 方法二：业务折衷法-禁止跳页查询

           a. 用正常的方法取得第一页数据，并得到第一页记录的time_max

           b. 每次翻页，将order by time offset X limit Y，改写成order by time where time>$time_max limit Y

           以保证每次只返回一页数据，性能为常量。

      3). 方法三：业务折衷法-允许模糊数据(多个数据库平均查出数据，损失一定的精度)

            a. 将order by time offset X limit Y，改写成order by time offset X/N limit Y/N

      4). 方法四：二次查询法

          a. 将order by time offset X limit Y，改写成order by time offset X/N limit Y

          b. 找到最小值time_min

          c. between二次查询，order by time between $time_min and $time_i_max

          d.设置虚拟time_min，找到time_min在各个分库的offset，从而得到time_min在全局的offset

          e. 得到了time_min在全局的offset，自然得到了全局的offset X limit Y

 

2. 单KEY业务，数据库水平切分架构实践

    1).水平切分方法

        a.范围法，以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：

           user-db1：存储0到1千万的uid数据

           user-db2：存储1到2千万的uid数据

           a).范围法的优点是：切分策略简单，根据uid，按照范围，user- center很快能够定位到数据在哪个库上 ; 扩容简单，如果容量不够，只要增加user-db3即可

           b).范围法的不足是：

           uid必须要满足递增的特性

           数据量不均，新增的user-db3，在初期的数据会比较少

           请求量不均，一般来说，新注册的用户活跃度会比较高，故user-db2往往会比user-db1负载要高，导致服务器利用率不平衡

       b.哈希法，也是以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：

          user-db1：存储uid取模得1的uid数据

          user-db2：存储uid取模得0的uid数据

          a).哈希法的优点是：切分策略简单，根据uid，按照hash，user-center很快能够定位到数据在哪个库上

              数据量均衡，只要uid是均匀的，数据在各个库上的分布一定是均衡的

             请求量均衡，只要uid是均匀的，负载在各个库上的分布一定是均衡的

         b).哈希法的不足是：扩容麻烦，如果容量不够，要增加一个库，重新hash可能会导致数据迁移，如何平滑的进行数据迁移，是一个需要解决的问题

     2).用户中心水平切分后带来的问题:

         对于uid属性上的查询可以直接路由到库，假设访问uid=124的数据，取模后能够直接定位db-user1：对于非uid属性上的查询，例如login_name属性上的查询，就悲剧了：

         假设访问login_name=shenjian的数据，由于不知道数据落在哪个库上，往往需要遍历所有库，当分库数量多起来，性能会显著降低。 

     3).根据楼主这些年的架构经验，用户中心非uid属性上经常有两类业务需求：

         a.用户侧，前台访问，最典型的有两类需求

            用户登录：通过login_name/phone/email查询用户的实体，1%请求属于这种类型

            用户信息查询：登录之后，通过uid来查询用户的实例，99%请求属这种类型

            用户侧的查询基本上是单条记录的查询，访问量较大，服务需要高可用，并且对一致性的要求较高。

         b.运营侧，后台访问，根据产品、运营需求，访问模式各异，按照年龄、性别、头像、登陆时间、注册时间来进行查询。

           运营侧的查询基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格。

           这两类不同的业务需求，应该使用什么样的架构方案来解决呢？ 

      4).用户中心水平切分架构思路

          用户中心在数据量较大的情况下，使用uid进行水平切分，对于非uid属性上的查询需求，架构设计的核心思路为：

         针对用户侧，应该采用“建立非uid属性到uid的映射关系”的架构方案

         针对运营侧，应该采用“前台与后台分离”的架构方案 

     5).用户中心-用户侧最佳实践

         a.索引表法 

            思路：uid能直接定位到库，login_name不能直接定位到库，如果通过login_name能查询到uid，问题解决

            解决方案：

            建立一个索引表记录login_name->uid的映射关系

            用login_name来访问时，先通过索引表查询到uid，再定位相应的库

            索引表属性较少，可以容纳非常多数据，一般不需要分库

            如果数据量过大，可以通过login_name来分库

            潜在不足：多一次数据库查询，性能下降一倍

        b.缓存映射法:

           思路：访问索引表性能较低，把映射关系放在缓存里性能更佳

           解决方案：

           login_name查询先到cache中查询uid，再根据uid定位数据库

           假设cache miss，采用扫全库法获取login_name对应的uid，放入cache

           login_name到uid的映射关系不会变化，映射关系一旦放入缓存，不会更改，无需淘汰，缓存命中率超高

           如果数据量过大，可以通过login_name进行cache水平切分

           潜在不足：多一次cache查询

        c.login_name生成uid:

          思路：不进行远程查询，由login_name直接得到uid

          解决方案：

          在用户注册时，设计函数login_name生成uid，uid=f(login_name)，按uid分库插入数据

          用login_name来访问时，先通过函数计算出uid，即uid=f(login_name)再来一遍，由uid路由到对应库

          潜在不足：该函数设计需要非常讲究技巧，有uid生成冲突风险 

       d.login_name基因融入uid

          思路：不能用login_name生成uid，可以从login_name抽取“基因”，融入uid中。假设分8库，采用uid%8路由，潜台词是，uid的最后3个bit决定这条数据落在哪个库上，这3个bit就是所谓的“基因”。

          解决方案：在用户注册时，设计函数login_name生成3bit基因，login_name_gene=f(login_name)，如上图粉色部分

                           同时，生成61bit的全局唯一id，作为用户的标识，如上图绿色部分

                          接着把3bit的login_name_gene也作为uid的一部分，如上图屎黄色部分

                          生成64bit的uid，由id和login_name_gene拼装而成，并按照uid分库插入数据

                         用login_name来访问时，先通过函数由login_name再次复原3bit基因，login_name_gene=f(login_name)，通过login_name_gene%8直接定位到库

       e.用户中心-运营侧最佳实践

          前台用户侧，业务需求基本都是单行记录的访问，只要建立非uid属性 login_name / phone / email 到uid的映射关系，就能解决问题。

          后台运营侧，业务需求各异，基本是批量分页的访问，这类访问计算量较大，返回数据量较大，比较消耗数据库性能。

          如果此时前台业务和后台业务公用一批服务和一个数据库，有可能导致，由于后台的“少数几个请求”的“批量查询”的“低效”访问，导致数据库的cpu偶尔瞬时100%，影响前台正常用户的访问（例如，登录超时）。 

          而且，为了满足后台业务各类“奇形怪状”的需求，往往会在数据库上建立各种索引，这些索引占用大量内存，会使得用户侧前台业务uid/login_name上的查询性能与写入性能大幅度降低，处理时间增长。

          对于这一类业务，应该采用“前台与后台分离”的架构方案：

          户侧前台业务需求架构依然不变，产品运营侧后台业务需求则抽取独立的web / service / db 来支持，解除系统之间的耦合，对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务：

          可以去掉service层，在运营后台web层通过dao直接访问db

          不需要反向代理，不需要集群冗余

          不需要访问实时库，可以通过MQ或者线下异步同步数据

          在数据库非常大的情况下，可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案

       f.总结

         将以“用户中心”为典型的“单KEY”类业务，水平切分的架构点，本文做了这样一些介绍。

         水平切分方式：范围法;哈希法

         水平切分后碰到的问题：通过uid属性查询能直接定位到库，通过非uid属性查询不能定位到库

         非uid属性查询的典型业务：用户侧，前台访问，单条记录的查询，访问量较大，服务需要高可用，并且对一致性的要求较高;运营侧，后台访问，根据产品、运营需求，访问模式各异，基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格

         这两类业务的架构设计思路：

         针对用户侧，应该采用“建立非uid属性到uid的映射关系”的架构方案

         针对运营侧，应该采用“前台与后台分离”的架构方案

          用户前台侧，“建立非uid属性到uid的映射关系”最佳实践：

         索引表法：数据库中记录login_name->uid的映射关系

        缓存映射法：缓存中记录login_name->uid的映射关系

        login_name生成uid

        login_name基因融入uid

        运营后台侧，“前台与后台分离”最佳实践：

        前台、后台系统web/service/db分离解耦，避免后台低效查询引发前台查询抖动

        可以采用数据冗余的设计方式

        可以采用“外置索引”（例如ES搜索系统）或者“大数据处理”（例如HIVE）来满足后台变态的查询需求

 

3. 100亿数据1万属性数据架构设计

     1). 什么是数据库扩展的version + ext方案？

          使用ext来承载不同业务需求的个性化属性，使用version来标识ext里各个字段的含义。

          优点:a.可以随时动态扩展属性，扩展性好 ;b.新旧两种数据可以同时存在，兼容性好

          不足:a.ext里的字段无法建立索引 ; b.ext里的key值有大量冗余，建议key短一些

     2). 如何将不同品类，异构的数据统一存储起来，采用的就是类似version+ext的方式：

          tiezi(tid,uid, time, title, cate, subcate, xxid, ext)

          a.一些通用的字段抽取出来单独存储

          b.通过cate, subcate, xxid等来定义ext是何种含义（和version有点像？）

          c.通过ext来存储不同业务线的个性化需求

     3). 解决了海量异构数据的存储问题，遇到的新问题是：

          a.每条记录ext内key都需要重复存储，占据了大量的空间，能否压缩存储

          b.cateid已经不足以描述ext内的内容，品类有层级，深度不确定，ext能否具备自描述性

          c.随时可以增加属性，保证扩展性

     4).统一类目属性服务

         抽象出一个统一的类目、属性服务，单独来管理这些信息，而帖子库ext字段里json的key，统一由数字来表示，减少存储空间。

         数字是什么含义，属于哪个子分类，值的校验约束，统一都存储在类目、属性服务里。

         除此之外，如果ext里某个key的value不是正则校验的值，而是枚举值时，需要有一个对值进行限定的枚举表来进行校验

     5). 统一检索服务

          数据量很大的时候，不同属性上的查询需求，不可能通过组合索引来满足所有查询需求，怎么办呢？

          58同城的先贤们，从一早就确定了“外置索引，统一检索服务”的技术路线：

          a.数据库提供“帖子id”的正排查询需求

          b.所有非“帖子id”的个性化检索需求，统一走外置索引

      6).元数据与索引数据的操作遵循：

          a.对帖子进行tid正排查询，直接访问帖子服务

          b.对帖子进行修改，帖子服务通知检索服务，同时对索引进行修改

          c.对帖子进行复杂查询，通过检索服务满足需求

 

4.数据库秒级平滑扩容架构方案

    1).部署方案：

         a.并发量大，流量大的互联网架构，一般来说，数据库上层都有一个服务层，服务层记录了“业务库名”与“数据库实例”的映射关系，通过数据库连接池向数据库路由sql语句以执行

         b.随着数据量的增大，数据要进行水平切分，分库后将数据分布到不同的数据库实例（甚至物理机器）上，以达到降低数据量，增强性能的扩容目的

         c.互联网架构需要保证数据库高可用，常见的一种方式，使用双主同步+keepalived+虚ip的方式保证数据库的可用性

         d.综合上文的（2）和（3），线上实际的架构，既有水平切分，又有高可用保证

         提问：如果数据量持续增大，分2个库性能扛不住了，该怎么办呢？

         回答：继续水平拆分，拆成更多的库，降低单库数据量，增加库主库实例（机器）数量，提高性能。

    2).停服务方案:暂停所有服务，迁移数据。

         回滚方案：如果数据迁移失败，或者迁移后测试失败，则将配置改回x库，恢复服务，改天再挂公告。

         方案优点：简单

         方案缺点：a.停服务，不高可用;

                           b.技术同学压力大，所有工作要在规定时间内做完，根据经验，压力越大约容易出错（这一点很致命）

                           c.如果有问题第一时间没检查出来，启动了服务，运行一段时间后再发现有问题，难以回滚，需要回档，可能会丢失一部分数据

     3).秒级、平滑、帅气方案

         a.修改配置

            主要修改两处：

            a).数据库实例所在的机器做双虚ip，原来%2=0的库是虚ip0，现在增加一个虚ip00，%2=1的另一个库同理

            b).修改服务的配置（不管是在配置文件里，还是在配置中心），将2个库的数据库配置，改为4个库的数据库配置，修改的时候要注意旧库与辛苦的映射关系：

                %2=0的库，会变为%4=0与%4=2；

                %2=1的部分，会变为%4=1与%4=3；

                这样修改是为了保证，拆分后依然能够路由到正确的数据。 

         b.reload配置，实例扩容

            服务层reload配置，reload可能是这么几种方式：

            a).比较原始的，重启服务，读新的配置文件

            b).高级一点的，配置中心给服务发信号，重读配置文件，重新初始化数据库连接池

                不管哪种方式，reload之后，数据库的实例扩容就完成了，原来是2个数据库实例提供服务，现在变为4个数据库实例提供服务，这个过程一般可以在秒级完成。

                整个过程可以逐步重启，对服务的正确性和可用性完全没有影响：

            a).即使%2寻库和%4寻库同时存在，也不影响数据的正确性，因为此时仍然是双主数据同步的

            b).服务reload之前是不对外提供服务的，冗余的服务能够保证高可用

              完成了实例的扩展，会发现每个数据库的数据量依然没有下降，所以第三个步骤还要做一些收尾工作 

        c.收尾工作，数据收缩:

           有这些一些收尾工作：

           a).把双虚ip修改回单虚ip

           b).解除旧的双主同步，让成对库的数据不再同步增加

           c).增加新的双主同步，保证高可用

           d).删除掉冗余数据，例如：ip0里%4=2的数据全部干掉，只为%4=0的数据提供服务啦

               这样下来，每个库的数据量就降为原来的一半，数据收缩完成。

 

5. 100亿数据平滑数据迁移,不影响服务

     针对互联网很多“数据量较大，并发量较大，业务复杂度较高”的业务场景，在

      a.底层表结构变更

      b.分库个数变换

      c.底层存储介质变换

      的众多需求下，需要进行数据迁移，完成“平滑迁移数据，迁移过程不停机，保证系统持续服务”有两种常见的解决方案。

      1).追日志法，五个步骤：

          a.服务进行升级，记录“对旧库上的数据修改”的日志

          b.研发一个数据迁移小工具，进行数据迁移

          c.研发一个读取日志小工具，追平数据差异

          d.研发一个数据比对小工具，校验数据一致性

          e.流量切到新库，完成平滑迁移

      2).双写法，四个步骤：

          a.服务进行升级，记录“对旧库上的数据修改”进行新库的双写

          b.研发一个数据迁移小工具，进行数据迁移

          c.研发一个数据比对小工具，校验数据一致性

          d.流量切到新库，完成平滑迁移

 

6. mysql冗余数据的三种方案

    1).为什么要冗余数据

        例如：订单业务，对用户和商家都有订单查询需求：

        Order(oid, info_detail);

        T(buyer_id, seller_id, oid);

        如果用buyer_id来分库，seller_id的查询就需要扫描多库。

        如果用seller_id来分库，buyer_id的查询就需要扫描多库。

        此时可以使用数据冗余来分别满足buyer_id和seller_id上的查询需求：

        T1(buyer_id, seller_id, oid)

        T2(seller_id, buyer_id, oid)

        同一个数据，冗余两份，一份以buyer_id来分库，满足买家的查询需求；一份以seller_id来分库，满足卖家的查询需求。

   2).服务同步双写

       顾名思义，由服务层同步写冗余数据，如上图1-4流程：

       业务方调用服务，新增数据

       服务先插入T1数据

       服务再插入T2数据

       服务返回业务方新增数据成功

       优点：

       不复杂，服务层由单次写，变两次写

       数据一致性相对较高（因为双写成功才返回）

       缺点：

       请求的处理时间增加（要插入两次，时间加倍）

        数据仍可能不一致，例如第二步写入T1完成后服务重启，则数据不会写入T2

    3).服务异步双写

        数据的双写并不再由服务来完成，服务层异步发出一个消息，通过消息总线发送给一个专门的数据复制服务来写入冗余数据，如上图1-6流程：

        业务方调用服务，新增数据

        服务先插入T1数据

        服务向消息总线发送一个异步消息（发出即可，不用等返回，通常很快就能完成）

        服务返回业务方新增数据成功

        消息总线将消息投递给数据同步中心

        数据同步中心插入T2数据

        优点：请求处理时间短（只插入1次）

       缺点：系统的复杂性增加了，多引入了一个组件（消息总线）和一个服务（专用的数据复制服务）

       因为返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）

       在消息总线丢失消息时，冗余表数据会不一致

       不管是服务同步双写，还是服务异步双写，服务都需要关注“冗余数据”带来的复杂性。如果想解除“数据冗余”对系统的耦合，引出常用的第三种方案。

        如果系统对处理时间比较敏感，引出常用的第二种方案。

   4).线下异步双写:

        为了屏蔽“冗余数据”对服务带来的复杂性，数据的双写不再由服务层来完成，而是由线下的一个服务或者任务来完成，如上图1-6流程：

        业务方调用服务，新增数据

        服务先插入T1数据

        服务返回业务方新增数据成功

        数据会被写入到数据库的log中

        线下服务或者任务读取数据库的log

        线下服务或者任务插入T2数据

        优点：数据双写与业务完全解耦； 请求处理时间短（只插入1次）

        缺点：返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）

                  数据的一致性依赖于线下服务或者任务的可靠性

   5).总结：

        互联网数据量大的业务场景，常常:

        使用水平切分来降低单库数据量

        使用数据冗余的反范式设计来满足不同维度的查询需求

       使用服务同步双写法能够很容易的实现数据冗余

       为了降低时延，可以优化为服务异步双写法

       为了屏蔽“冗余数据”对服务带来的复杂性，可以优化为线下异步双写法

 

内容转自微信公众号：架构师之路