JAVA架构师大型分布式高并发电商项目实战，性能优化，集群，亿级高并发，web安全，缓存架构实战

现任58到家技术委员会主席，高级技术总监，负责企业，支付，营销、客户关系等多个后端业务部门。本质，技术人一枚。互联网架构技术专家，“架构师之路”公众号作者。曾任百度高级工程师，58同城高级架构师，58同城技术委员会主席，58同城C2C技术部负责人。

内容介绍

1.大数据量时，数据库架构设计原则

2.数据库水平切分架构设计方向

3.用户中心，帖子中心，好友中心，订单中心水平切分架构实践

下面是58沈剑老师的演讲实录

大家好，我是58沈剑，架构师之路的小编，后端程序员一枚，平时比较喜欢写写文字。今天和大家分享，数据量很大的情况下，如何进行数据库架构设计（主要是水平切分）会举用户中心，帖子中心，订单中心的一些例子，希望大家有收获。

首先，介绍数据库架构设计中的一些基本概念，常见问题以及对应解决方案，为了便于读者理解，将以“用户中心”数据库为例，讲解数据库架构设计的常见玩法。

第一个概念是“单库”。

user-service：用户中心服务，对调用者提供友好的RPC接口，user-db：单库（就是一个库）进行数据存储。

第二个概念是“分组”。

什么是分组？分组架构是最常见的一主多从，主从同步，读写分离数据库架构

user-service：依旧是用户中心服务 
user-db-M(master)：主库，提供数据库写服务 
user-db-S(slave)：从库，提供数据库读服务 
主和从构成的数据库集群称为“组”。分组解决的是“数据库读写高并发量高”问题。

第三个概念是“分片”。

分片架构是大伙常说的水平切分(sharding)数据库架构。

user-db1：水平切分成2份中的第一份，user-db2：水平切分成2份中的第二份，分片后，多个数据库实例也会构成一个数据库集群。一旦分片，就涉及分片算法。常见的水平切分算法有“范围法”和“哈希法”

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

哈希法如上图 
user-db1：存储uid取模得1的uid数据，user-db2：存储uid取模得0的uid数据。这两种分片算法，在互联网都有使用，其中哈希法使用较为广泛。

分片解决的是“数据库数据量大”问题，也就是今天数据库架构分享的主题。

场景一、用户中心

第一个案例，先以“用户中心”为例，介绍“单KEY”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践。

用户中心是一个非常常见的业务，主要提供用户注册、登录、信息查询与修改的服务。其核心元数据为： 
User(uid, login_name, passwd, sex, age, nickname, …); uid为用户ID，主键。login_name, passwd, sex, age, nickname, …等用户属性。数据库设计上，一般来说在业务初期，单库单表就能够搞定这个需求。

当数据量越来越大时，需要多用户中心进行水平切分，上文提到了“范围法”与“哈希法”。使用uid来进行水平切分之后，整个用户中心的业务访问会遇到什么问题呢？对于uid属性上的查询可以直接路由到库，对于非uid属性上的查询，例如login_name属性上的查询，就悲剧了。

例如，按照uid分为3个库，使用login_name=shenjian来查询，就不知道数据分布在哪个库上了。一种方法，是遍历所有库，当分库数量多起来，性能会显著降低。

常见的解决方案，有这么四种方法：

第一种方法，索引表法

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

细致的步骤为：

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

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

（3）索引表属性较少，只有两列，可以容纳非常多数据，一般不需要分库

（4）如果数据量过大，可以通过login_name来分库；

潜在的不足是：多一次数据库查询，性能会有所下降。

第二种方法，缓存映射法

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

细致的步骤为：

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

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

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

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

潜在的不足是：多了一次cache查询。

第三种方法，login_name生成uid法

思路：不进行额外查询，能由login_name直接生成uid么？

细致的步骤为：

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

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

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

第四种方法，基因法（这个方法网上没有，在“架构是之路”公众号里有说明过） 
思路：不用login_name生成uid，可以从login_name抽取“基因”，融入uid中。 
方法图示如下（这个图很重要）：

假设分8库，采用uid%8路由。潜台词是，uid的最后3个bit决定这条数据落在哪个库上，这3个bit就是所谓的“基因”。

细致的步骤为：

（1）在用户注册时，设计函数login_name生成3bit基因，login_name_gene=f(login_name)，如上图粉色部分；【画外音，一定要步骤和图对着看】

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

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

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

（5）用login_name来访问时，先通过函数由login_name再次复原3bit基因，login_name_gene=f(login_name)，通过login_name_gene%8直接定位到库。如此这般，uid可以直接定位到库，login_name可以生成基因，也可以定位到库。

好，用户中心是第一个场景。

场景二、帖子中心

第二个场景，将以“帖子中心”为例，介绍“1对多”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践。用户中心，是一个但key场景，而帖子中心，是一个1对多的场景。

什么是1对多场景？

一个用户可以发多条微博，一条微博只有一个发送者；一个uid对应多个msg_id，一个msg_id只对应一个uid；这些是1对多的关系。

一个用户可以发布多个帖子，一个帖子只对应一个发布者。帖子中心，是一个提供帖子发布，修改，删除，查看，搜索的服务。

读操作：通过tid查询帖子实体，单行查询；通过uid查询用户发布过的帖子，列表查询。帖子检索，例如通过时间、标题、内容搜索符合条件的帖子。

写操作：发布(insert)帖子；修改(update)帖子；删除(delete)帖子。

在数据量较大，并发量较大的时候，通常通过元数据与索引数据分离的架构来满足实时查询，以及帖子检索的入球。

架构中的几个关键点 
（1）tiezi-center服务； 
（2）tiezi-db：提供元数据存储； 
（3）tiezi-search搜索服务； 
（4）tiezi-index：提供索引数据存储； 
（5）MQ：tiezi-center与tiezi-search通讯媒介，一般不直接使用RPC调用，而是通过MQ对两个子系统解耦；

【画外音：12345对着图细看一下】

如上图所示：tid和uid上的查询需求，可以由tiezi-center从元数据读取并返回，其他检索需求，可以由tiezi-search从索引数据检索并返回，tiezi-search可以使用Solr，ES等开源架构实现，这一块不是今天的重点，今天将重点描述帖子中心元数据这一块的水平切分设计。在业务初期，单库就能满足元数据存储要求。

在相关字段上建立索引，就能满足相关业务需求，帖子记录查询，通过tid查询，约占读请求量的90% 。select * from t_tiezi where tid=$tid 帖子列表查询，通过uid查询其发布的所有帖子，约占读请求量的10% ，select * from t_tiezi where uid=$uid。当数据量越来越大时，需要对帖子数据的存储进行线性扩展，既然是帖子中心，并且帖子记录查询量占了总请求的90%，很容易想到通过tid字段取模来进行水平切分。

这个方法简单直接。但缺点是：一个用户发布的所有帖子可能会落到不同的库上，10%的请求通过uid来查询会比较麻烦。

一个uid查询帖子列表，需要遍历所有库。有没有一种切分方法，确保同一个用户发布的所有帖子都落在同一个库上，而在查询一个用户发布的所有帖子时，不需要去遍历所有的库呢？

使用uid来分库可以解决这个问题。

新增一个索引库：t_mapping(tid, uid)

（1）这个库只有两列，可以承载很多数据；

（2）即使数据量过大，索引库可以利用tid水平切分；

（3）这类kv形式的索引结构，可以很好的利用cache优化查询性能；

（4）一旦帖子发布，tid和uid的映射关系就不会发生变化，cache的命中率会非常高；

如此这般，可以保证一个uid的所有tid都在一个库上，使用tid查询时，先通过mapping库查询到uid，再定位库，这就是帖子中心场景，使用uid来进行分库的好处。

mapping表法，和用户中心的索引表很像，那是不是也能使用“基因法”呢？答案是肯定的，如果login_name生成基因打入uid一样，可以在uid上取基因，打入tid。

如上图所示，假设分为16库，用uid%16分库，假设uid=666的用户发布了一条帖子

（1）使用uid%16分库，决定这行数据要插入到哪个库中；

（2）%16，即分库基因是uid的最后4个bit，即1010；

（3）在生成tid时，先使用一种分布式ID生成算法生成前60bit（上图中绿色部分）；

（4）将分库基因加入到tid的最后4个bit（上图中粉色部分），拼装成最终的64bit帖子tid（上图中蓝色部分）；

【画外音，对照上图看1234】

通过这种方法保证，同一个用户发布的所有帖子的tid，都落在同一个库上，tid的最后4个bit都相同

于是，通过uid%16能够定位到库，通过tid%16也能定位到库，基因法很有意思，网上几乎没有文章介绍，更详细的基因法介绍，可以扫下列二维码查阅。

没错，就是架构师之路，基因法，哈哈。

场景三、好友中心

第三个场景，是好友中心，好友中心，是一个多对多的场景。

什么是多对多关系？

所谓的“多对多”，来自数据库设计中的“实体-关系”ER模型，用来描述实体之间的关联关系。一个学生可以选修多个课程，一个课程可以被多个学生选修，这里学生与课程时间的关系，就是多对多关系。

好友中心是一个典型的多对多业务，一个用户可以关注多个好友，也可以被多个好友关注。

friend-service：好友中心服务，对调用者提供友好的RPC接口，guanzhu表，用户记录uid所有关注用户guanzhu_uid。fensi表，用来记录uid所有粉丝用户fensi_uid。一条好友关系的产生，会产生两条记录，一条关注记录，一条粉丝记录。数据量大时，如何进行水平切分呢？关注表，使用uid分库，存储的是关注的人。粉丝表，也使用uid分库，存储的是粉丝。由于一条好友关系的产生，会产生两条记录，分库的时候要注意，需要保证数据的一致性，关注库，粉丝库，可能存储在不同的数据实例上，数据的插入难以保证原子性。

这是一个很难的“分布式事务”的问题。具体的数据冗余方式，常见的有这么两种： 
第一种，同步冗余。

顾名思义，由好友中心服务同步写冗余数据。如上图1-4流程 
（1）业务方调用服务，新增好友关系数据； 
（2）服务先插入T1数据； 
（3）服务再插入T2数据； 
（4）服务返回业务方新增数据成功；

第二种，异步冗余

服务层异步发出一个消息，通过消息总线发送给一个专门的数据复制服务来写入冗余数据。如上图1-6流程 
（1）业务方调用服务，新增数据； 
（2）服务先插入T1数据； 
（3）服务向消息总线发送一个异步消息（发出即可，异步不用等返回，通常很快就能完成）； 
（4）服务返回业务方新增数据成功； 
（5）消息总线将消息投递给数据同步中心； 
（6）数据同步中心插入T2数据； 
这是两种很常见的冗余数据的方式。数据的一致性如何保证？如果插入T1数据，T2数据插入失败呢？需要有一个校验机制。这里多提一句，为了保证一致性，架构设计的思路有两种：

（1）分布式事务，保证强一致；

（2）新增异步校验机制；

第一个方向，很难，是业界没有解决的难题。或者说，即使有理论上可行的方案，算法效率也非常非常低，不适合互联网高并发场景。此时的架构优化方向，并不是完全保证数据的一致，而是尽早的发现不一致，并修复不一致。校验机制，又有两种常见的方法。 
一种是异步扫描校验

线下启动一个离线的扫描工具，不停的比对正表T1和反表T2，如果发现数据不一致，就进行补偿修复，这个方法是最容易想到的。 
一种是实时消息扫描校验

（1）写入正表T1； 
（2）第一步成功后，发送消息msg1； 
（3）写入反表T2； 
（4）第二步成功后，发送消息msg2； 
正常情况下，msg1和msg2的接收时间应该在3s以内，如果检测服务在收到msg1后没有收到msg2，就尝试检测数据的一致性，不一致时进行补偿修复。第一个方案比较容易，但时效性差，第二个方案比较复杂，但时效好。这里再强调一下，分布式事务一致性，是我被询问最多的问题。 无数网友在公众号下方留言问，分布式事务一致性的问题。

这里再强调一下方法论。高吞吐互联网业务，要想完全保证事务一致性很难，常见的实践是最终一致性 。最终一致性的常见实践是，尽快找到不一致，并修复数据。

场景四、订单中心

第四个场景，也是最后一个场景，是最复杂的，订单中心的分库。这是一个多key的场景。

Order(oid, buyer_uid, seller_uid, time, money, detail…);为啥叫多key呢

（1）oid为订单ID，主键；

（2）buyer_uid为买家uid；

（3）seller_uid为卖家uid；

看到了吧，访问模式有多个。随着订单量的越来越大，数据库需要进行水平切分，由于存在多个key上的查询需求，用哪个字段进行切分，成了需要解决的关键技术问题。

如果用oid来切分，buyer_uid和seller_uid上的查询则需要遍历多库，如果用buyer_uid或seller_uid来切分，其他属性上的查询则需要遍历多库。

思路为，多个维度的查询较为复杂，对于复杂系统设计，可以逐步简化。假设没有seller_uid，订单中心，假设没有seller_uid上的查询需求，而只有oid和buyer_uid上的查询需求，应该怎么分库？

没错，没有seller_uid，就蜕化为一个“1对多”的业务场景，对于“1对多”的业务，水平切分应该使用“基因法”。

再次回顾一下，什么是分库基因？通过buyer_uid分库，假设分为16个库，采用buyer_uid%16的方式来进行数据库路由，所谓的模16，其本质是buyer_uid的最后4个bit决定这行数据落在哪个库上，这4个bit，就是分库基因。在订单数据oid生成时，oid末端加入分库基因，让同一个buyer_uid下的所有订单都含有相同基因，落在同一个分库上。

再次假设，这个场景如果没有订单ID的oid呢？假设没有oid上的查询需求，而只有buyer_uid和seller_uid上的查询需求，就蜕化为一个“多对多”的业务场景。对于“多对多”的业务，就和好友中心一样，水平切分应该使用“数据冗余法”（上面提到的关注库，粉丝库）。

订单中心，该怎么弄呢？任何复杂难题的解决，都是一个化繁为简，逐步击破的过程。对于像订单中心一样复杂的“多key”类业务，在数据量较大，需要对数据库进行水平切分时：

（1）使用“基因法”，解决“1对多”分库需求：使用buyer_uid分库，在oid中加入分库基因，同时满足oid和buyer_uid上的查询需求；

（2）使用“数据冗余法”，解决“多对多”分库需求：使用buyer_uid和seller_uid来分别分库，冗余数据，满足buyer_uid和seller_uid上的查询需求；

（3）订单中心，oid/buyer_uid/seller_uid同时存在，可以使用上述两种方案的综合方案，来解决“多key”业务的数据库水平切分难题；

今天的分享差不多就到这里，最后做一个小结

水平切分方式；

范围法；

哈希法；

用户侧，“建立非uid属性到uid的映射关系”最佳实践。索引表法：数据库中记录login_name->uid的映射关系。缓存映射法：缓存中记录login_name->uid的映射关系。生成法：login_name生成uid；基因法：login_name基因融入uid；

帖子侧，帖子服务，元数据满足uid和tid的查询需求。搜索服务，索引数据满足复杂搜索寻求。uid切分法，按照uid分库，同一个用户发布的帖子落在同一个库上，需要通过索引表或者缓存来记录tid与uid的映射关系，通过tid来查询时，先查到uid，再通过uid定位库。基因法，按照uid分库，在生成tid里加入uid上的分库基因，保证通过uid和tid都能直接定位到库。

好友侧，数据冗余是一个常见的多对多业务数据水平切分实践。冗余数据的常见方案有两种：服务同步冗余，服务异步冗余（通过MQ发消息）。数据冗余会带来一致性问题，高吞吐互联网业务，要想完全保证事务一致性很难，常见的实践是最终一致性。最终一致性的常见实践是，尽快找到不一致，并修复数据，常见方案有：线下扫描法，实时消息法。

订单侧，任何复杂难题的解决，都是一个化繁为简，逐步击破的过程。将“多key”类业务，分解为“1对多”类业务和“多对多”类业务分别解决。使用“基因法”，解决“1对多”分库需求：使用buyer_uid分库，在oid中加入分库基因，同时满足oid和buyer_uid上的查询需求。使用“数据冗余法”，解决“多对多”分库需求：使用buyer_uid和seller_uid来分别分库，冗余数据，满足buyer_uid和seller_uid上的查询需求。oid/buyer_uid/seller_uid同时存在，可以使用上述两种方案的综合方案，来解决“多key”业务的数据库水平切分难题。

最后再多说一句，任何脱离业务的架构设计都是耍流氓，共勉。

今天，仅仅只是展开描述了“水平切分”这一个话题，在数据库架构设计过程中，除了水平切分，至少还会遇到这样一些问题：

（1）可用性：不管是主库实例，还是从库实例，如果数据库实例挂了，如何不影响数据的读和写；

（2）读性能：互联网业务大多是读多写少的业务，如果提升数据库的读性能是架构设计中必须考虑的问题；（3）一致性：数据一旦冗余，就可能出现一致性问题，如何解决主库与从库之间的不一致，如何解决数据库与缓存之间的不一致，也是需要重点设计的；

（4）扩展性：如何在不停服务的情况下扩充数据表的属性，实施数据迁移，实施存储引擎的切换，架构设计上都是十分有讲究的；

（5）分布式SQL语句：单库情况下，所有SQL语句的执行都没问题问题，一旦实施了水平切分，如何实现SQL的集函数，分页，非patition key上的查询都成了大问题；

上面这些问题，由于时间的关系，今天不能再展开。要想了解细节，你懂的，扫描上面的二维码，微信关注“架构师之路”，有你想要的答案。对于“数据库水平切分”，希望大家有收获，希望下次还有机会在51CTO群里分享。

以下问题是来自51CTO开发者社群小伙伴们的提问和分享

Q：Java-风-阿里：老师分布式事务玩过TCC吗？

A：58沈剑老师：高并发的场景，基本不玩分布式事务，1秒几十万次的并发，分布式事务扛不住的。

Q：后端-陈医生-北京：说的基因法和数据冗余法，不是非常懂，尤其订单那块的基因法。请教一个对于分库算法的问题，在分库算法都有什么？

A：58沈剑老师：今天介绍了，范围法，hash法。hash法，最常见的是取模，网上讨论最多的是一致性hash。强烈建议前者 ，取模就行。