数据的读多写少和读多写多解决方案

数据读多写少和读多写多

读多写少的场景

普遍来说，绝大多数的系统都是读多写少的，包括电商系统电商系统，新闻系统，论坛系统，在线教育、ERP，校园网系统都是属于读多写少的范畴。

读多写少的解决方案

可以把MySQL组建集群，并且设置上读写分离

写多读少的业务场景

比如说我们用滴滴出行APP预约了专车，当行程开始之后，滴滴APP就会实时上传专车的泄露信息。这么做也是为了乘客的安全考虑，那么实时上传的数据都会保存在数据库里边，而且这些数据很少被查询。只有在乘客报警或者发生纠纷的情况下，滴滴才会调取这一次专车出行的线路数据，所以这是一个明显的写多读少的场景。

再有大学食堂的结算系统也是明显的，写多读少，大量的刷卡信息被保存在数据库中，但是很少被查询。

写多读少的解决方案

如果是低价值的数据，可以采用NoSQL数据库来存储这些数据。

如果是高价值的数据，可以用TokuDB来保存。

读多写多的场景

微信和QQ都具有离线留言的功能。即便对方没有上线，我们发出去的消息会被临时存储在服务器上，等到对方上线之后就能收到这些离线的消息。微信和QQ的用户数量非常庞大，有很多离线消息，很多用户上线之后还要去获取离线消息。这在数据库来看离线消息的存储就是读多写多的。

读多写多的解决方案

传统的关系型数据库是没有办法应对这个业务场景。只能求助NoSQL数据库。

数据库集群方案的缺点

• 数据库集群的数据读写速度赶不上单节点的数据库

比方用三个mysql节点组建了集群，然后由MyCat来管理集群。当要存储一条商品记录的时候，MyCat要生成全局主键，然后还要去判断商品是什么类型的。

如果是电器类的商品，它就会把SQL语句转发给第一个mysql。如果商品是厨具，那么MyCat就会把这个insert语句转发给第二个my sq l节点。如果商品是食品,它的insert语句要转发给第三个mysql来执行。

正是因为MyCat要做一些额外的工作。会有少许的损耗，所以数据库集群的写入速度肯定是不如单节点mysql。

数据库集群方案的优点

• 数据库集群的意义在于它能支撑更大规模的并发访问。
• 能够存放更多数据

单节点的mysql难以支持500个并发连接。但是用了数据库集群之后这个并发的数量就会翻倍。

商品按类型存放在不同数据库中，每个节点的单表数据量就减少了。

而且在给mysql节点配上融余的备份节点，比如说第一个mysql节点挂掉了，那么它的备份节点就可以立即投入使用。抵御故障的能力也比单节点mysql好。