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).总结：
互联网数据量大的业务场景，常常:
使用水平切分来降低单库数据量
使用数据冗余的反范式设计来满足不同维度的查询需求
使用服务同步双写法能够很容易的实现数据冗余
为了降低时延，可以优化为服务异步双写法
为了屏蔽“冗余数据”对服务带来的复杂性，可以优化为线下异步双写法
内容转自微信公众号：架构师之路