数据库业务层扩展

数据库业务层扩展

读写分离

优势

• 实现简单，框架成熟，应用搭建简单。
• 在业务进行隔离，个业务不会相互影响。
• 能有效的减少数据库读的压力。

缺点

• 读实例的数据是从主实例上异步复制的，存在毫秒级的延迟，当需要实时性、强一致的时候读操作还是要在主库上。
• 主库存在单点问题。

分库分表

解决因单表数据量过大而导致的数据库性能问题，实现较为复杂，需要增加数据访问层。

两个关注点

• 数据分片策略，将数据按照某种策略分到多个库和多个表中。
• 数据访问层，为了让业务端系统对数据访问无感知，需要引入数据访问层来做数据路由（需要有sql解析能力，根据解析好的sql来做路由）。

数据分片策略

1. 按多租户方式，比如按租户ID来分，将同一个租户ID的数据分在一起，可以将租户隔离开。
2. 按商品类型，不同商品类型的数据分到一起，如电商平台中的商品系统。
3. 通过范围分片，这样可以保证同一范围内的数据在同一个分片中，如电商平台中的订单系统可以按照月份来进行分表。
4. 通过hash散列算法（如 id % 3得到数据存放位置），此策略可以有效的降低热点数据的形成。但是此方法会带来两个问题，一个是跨库跨表的查询和事务问题，另一个是数据库需要横行扩展时需要重新hash部分或所有的数据。

数据分片需要从业务角度出发，考虑业务层面的相关问题，而不是从技术实现角度

注意事项

1. 数据分片后很难保证跨分片的事务，所以应该尽量避免跨分片的数据操作，如果一定要需要评估一致性和是否使用两阶段提交。
2. 复杂的查询尽量使用ElasticSearch；报表类的功能使用Hadoop等大数据工具处理；避免从多个分片中检索数据如果一定要，可以在业务层分多个任务对各个分片单独查询后汇总。
3. 数据分片需要变更时一定要慎重，从线上拉数据下来，做好充分测试。

踩过的坑

1. 最好不要使用hash分片方式。之前的业务系统使用hash分片，当单表的数据量不能在扩容时（眼看数据库就要爆掉了），这时需要对数据库水平扩展，但是所有的数据都要重新hash，一是成本太高（中间件不支持数据重新hash，需要自己写代码实现），二是风险太高（一旦数据出问题后果很严重）。后来只做了数据归档（勉强维持，数据库使用量一直在90%左右）。

分库分表中间件

中间件	现状	友好度	事务支持	接入形式
MyCat	由阿里开源的Cobar发展而来的，社区活跃	使用NIO，支持绝大多数数据库	支持XA分布式事务	需要单独部署
Sharding-jdbc	Apache基金会孵化	目前支持MySQL，Oracle，SQLServer和PostgreSQL	支持XA分布式事务	jar包形式引入

转载于:https://my.oschina.net/u/1187203/blog/3054493