别再问“分库分表”了，再问就崩溃了！(6)

②前台与后台分离

对于用户侧，主要需求是以单行查询为主，需要建立 login_name/phone/email 到 uid 的映射关系，可以解决这些字段的查询问题。

而对于运营侧，很多批量分页且条件多样的查询，这类查询计算量大，返回数据量大，对数据库的性能消耗较高。

此时，如果和用户侧共用同一批服务或数据库，可能因为后台的少量请求，占用大量数据库资源，而导致用户侧访问性能降低或超时。

这类业务最好采用"前台与后台分离"的方案，运营侧后台业务抽取独立的 service 和 DB，解决和前台业务系统的耦合。

由于运营侧对可用性、一致性的要求不高，可以不访问实时库，而是通过 binlog 异步同步数据到运营库进行访问。

在数据量很大的情况下，还可以使用 ES 搜索引擎或 Hive 来满足后台复杂的查询方式。

支持分库分表中间件

站在巨人的肩膀上能省力很多，目前分库分表已经有一些较为成熟的开源解决方案：

sharding-jdbc(当当)

https://github.com/shardingjdbc

TSharding(蘑菇街)

https://github.com/baihui212/tsharding

Atlas(奇虎360)

https://github.com/Qihoo360/Atlas

Cobar(阿里巴巴)

https://github.com/alibaba/cobar

MyCAT(基于 Cobar)

Oceanus(58 同城)

https://github.com/58code/Oceanus

Vitess(谷歌)

https://github.com/vitessio/vitess

参考文章：

数据库分布式架构扫盲——分库分表(及银行核心系统适用性思考)

分库分表的思想

水平分库分表的关键步骤以及可能遇到的问题

从原则、方案、策略及难点阐述分库分表

Leaf——美团点评分布式 ID 生成系统

架构师之路公众号

（编辑：ASP站长网）