别再问“分库分表”了，再问就瓦解了！

②前台与靠山疏散

对付用户侧，首要需求是以单行查询为主，必要成立 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 天生体系

架构师之路公家号

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!