用户中心，1亿数据，架构如何设计？ _架构

本文较长，可提前收藏。
用户中心，几乎是所有互联网公司，必备的子系统。随着数据量不断增加，吞吐量不断增大，用户中心的架构，该如何演进呢。
什么是用户中心业务？
用户中心是一个通用业务，主要提供用户注册、登录、信息查询与修改的服务。
用户中心的数据结构是怎么样的？
用户中心的核心数据结构为：
User(uid, login_name, passwd, sex, age, nickname, …)
其中：
（1）uid为用户ID，为主键；
（2）login_name, passwd, sex 等是用户属性；
其系统架构又是怎么样的呢？
在业务初期，单库单表，配合用户中心微服务，就能满足绝大部分业务需求，其典型的架构为：

文章插图

（1）user-center：用户中心服务，对调用者提供友好的RPC接口；
（2）user-db：对用户进行数据存储；
当数据量越来越大，例如达到1亿注册量时，会出现什么问题呢？
随着数据量越来越大，单库无法承载所有的数据，此时需要对数据库进行水平切分。
常见的水平切分算法有“范围法”和“哈希法” 。
水平切分，什么是范围法？
范围法，以用户中心的业务主键uid为划分依据，采用区间的方式，将数据水平切分到两个数据库实例上去：

文章插图

（1）user-db1：存储0到1千万的uid数据；
（2）user-db2：存储1千万到2千万的uid数据；
范围法有什么优点？
（1）切分策略简单，根据uid，按照范围，user-center很快能够定位到数据在哪个库上；
（2）扩容简单，如果容量不够，只要增加user-db3，拓展2千万到3千万的uid即可；
范围法有什么缺点？
（1）uid必须要满足递增的特性；
（2）数据量不均，新增的user-db3，在初期的数据会比较少；
（3）请求量不均，一般来说，新注册的用户活跃度会比较高，故user-db2往往会比user-db1负载要高，导致服务器利用率不平衡；
画外音：数据库层面的负载均衡，既要考虑数据量的均衡，又要考虑负载的均衡。
水平切分，什么是哈希法？
哈希法，也是以用户中心的业务主键uid为划分依据，采用哈希的方式，将数据水平切分到两个数据库实例上去：

文章插图

（1）user-db1：存储奇数的uid数据；
（2）user-db2：存储偶数的uid数据；
哈希法有什么优点？
（1）切分策略简单，根据uid，按照hash，user-center很快能够定位到数据在哪个库上；
（2）数据量均衡，只要uid是随机的，数据在各个库上的分布一定是均衡的；
（3）请求量均衡，只要uid是随机的，负载在各个库上的分布一定是均衡的；
画外音：如果采用分布式id生成器，id的生成，一般都是随机的。
哈希法有什么缺点？
（1）扩容麻烦，如果容量不够，要增加一个库，重新hash可能会导致数据迁移；
用户中心架构，实施了水平切分之后，会带来什么新的问题呢？
使用uid来进行水平切分之后，对于uid属性上的查询，可以直接路由到库，假设访问uid=124的数据，取模后能够直接定位db-user1：

文章插图

但对于非uid属性上的查询，就悲剧了，例如login_name属性上的查询：

文章插图

假设访问login_name=shenjian的数据，由于不知道数据落在哪个库上，往往需要遍历所有库，当分库数量多起来，性能会显著降低。
用户中心，非uid属性查询，有哪些业务场景？
任何脱离业务的架构设计都是耍流氓。
在进行架构讨论之前，先来对业务进行简要分析，用户中心非uid属性上，有两类典型的业务需求。
第一大类，用户侧，前台访问，最典型的有两类需求：
（1）用户登录：通过登录名login_name查询用户的实体，1%请求属于这种类型；
（2）用户信息查询：登录之后，通过uid来查询用户的实例，99%请求属这种类型；
用户侧的查询，基本上是单条记录的查询，访问量较大，服务需要高可用，并且对一致性的要求较高。
第二大类，运营侧，后台访问，根据产品、运营需求，访问模式各异，按照年龄、性别、头像、登陆时间、注册时间来进行查询。