读多写少，读多写多

这篇文章没有什么操作性，主要是让伙伴们开拓视野的，通过一些使用场景，并没有太多上手的操作。

读多写少的业务场景

• 普遍来说，绝大多数系统都是读多写少的

也就是select语句执行的多，而insert、delete、update这样的操作执行的很少，比如

上面都是属于读多写少的范畴，就那在线购物来说

我们在淘宝上看的多买的少，也就是货比三家后才下单，我们在货比三家的过程中，其实产生了很多查询的操作，只有在下单的时候才产生了insert操作。

再比如我们在手机上看了多条新闻，才回复一条评论。再有就是58同城、大众点评也都是读多写少。

因为数据库就为CRUD这些操作设计的，所以这些场景，关系型数据库就足以应付了，无论使用MySQL呀、Oracle呀都是没有问题，如果并发量很大的话，可以组建MysQL集群来应对。

写多读少的场景

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

大学食堂也是写多读少的场景，写多读少的业务场景里，使用普通的关系型数据库可以吗？

写多读少的解决方案1

• 如果写多读少是低价值的数据，可以采用NoSQL数据库来存储这些数据

什么是低价值的数据呢？比如说线路的坐标，虽然数据很多，但是每条数据的价值不是很大，用MySQL这样的关系型数据库去存储，那么事务上的开销就让我们无法承受。因为在事务这个机制下面，写入数据之前都要先写undo日志、然后还要写redo日志，都没有问题了，等到事务提交的时候，再把redo日志里面的数据同步到数据文件里。

在读多写少的场景下，虽然事务下的数据库写入速度并不是特别快，但是写入的业务量并不是很大，所以看不出很么问题。但是，在写多读少的场景里，每一秒的写入大量数据，事务机制就会拖累写入的速度，因此说传统的关系型数据库就不太适合了，但我们要独辟蹊径才行。

就目前来说，最好的办法是使用NoSQL数据库，比如Mongodb这样的NoSQL产品的读写性能非常好，这是因为NoSQL数据库抛弃复杂的表结构和字段约束，甚至去除了事务机制，在写入数据的时候，不需要做sql语法校验和优化，也不用写undo、redo日志，那么数据的写入速度，是远远超过关系型数据库的。

保存低价值数据使用NoSQL数据库是再适合不过了。我们在创建数据的时候，需要创建两个数据源

写多读少的解决方案2

• 如果是高价值的数据，无法承受数据的丢失，可以用TokuDB来保存

比方说刷卡消费的数据就非常重要，因为所有的NoSQL数据库都是不支持事务的，所以它们不适合保存高价值数据，还得传统的关系型数据库才行，但是传统的MySQL数据库写入性能是非常低下的。所以我们需要专门为写入优化的数据库产品，恰好MySQL有一个数据库引擎叫TokuDB，它可以带着事务保持数据的高速写入。

• TokuDB的写入速度是InnoDB的9~20倍，数据的压缩比大概是InnoDB的15倍

光是这个写入速度都赶上NoSQL数据库了，那么TokuDB可以说是MySQL领域最好的引擎了，所以我们在设计业务系统的时候，传统的数据可以保存在普通的MySQL数据库里面，但是大规模写入的数据我们可以使用TokuDB来存储。至于怎么安装TokuDB数据库呢？可以百度下，这方面的资料非常多。

写多读多的业务场景

这种场景比较特殊，并不常见。比如说微信、qq具有离线留言的功能，即便对方没有上线，我们发出去的消息会被临时存储在数据库上，等到对方上线的时候，就能收到这些离线的消息了，微信、QQ的用户量很大，很多离线的消息要存储，很多用户上线后还要去获取离线消息

所以在数据库这端来是看，离线消息的存储就是读多写多的，传统的关系型数据库，是没有办法应对这个场景的，所以我们呢只能求助NoSQL数据库了。包括微信朋友圈也是读多写多的场景，那么朋友圈的数据也是存储在NoSQL数据库上的

数据库集群的方案缺点

不管什么样的业务场景，只要用到了数据库，就要建立集群，关系型数据库可以搭建集群，NosQL数据库也可以搭建集群。
其实

• 数据库集群的读写速度低于单节点的数据库实例

用MySQL举个例子，下图有三个MySQL节点搭建的集群，用MyCAT来管理集群，

当我们要保存一条商品记录的时候，MyCat要生成全局主键，然后还要看商品是什么类型的，如果是是电器类型的商品，就会把sql语句转发给第一个Mysql存储；如果是是厨具就会转发给第二个Mysql，依次类推，如果是食品的商品会转发给第三个mysql节点。正因为MyCAT要做这些额外的工作，在这里回有少许的损耗，所以数据库的集群写入速度，肯定比不上单节点的MySQL的。

数据库集群方案的优点

有童鞋会产生疑问，既然集群的速度赶不上单节点的速度，那我我们为什么还要搞集群呢？下面就说下原因

• 数据库集群能支持更大规模的并发访问，并且存放更多数据
  1. 比如单节点的难以支持500个并发连接，用上集群后数量就会翻倍。单节点在高并发的时候，实际性能很多童鞋是深有体会，比如很多大学的校园网都是单节点的部署，等到期末考试后，大家在同一天去校园网查询考试成绩，当天的校园网加载速度是非常慢的，浏览器半天也刷不出来网页，单节点的数据库支持1万的并发访问都很困难，我们怎么敢在网站上使用单节点的数据库呢？所以我们必须要对数据库做集群，并发性才能上去。
  2. 用了集群可以存放更多数据，因为InnoDB引擎单表数据量如果超过2000万，这个数据表读写速度就会明显的下降，因此我们可以把数据切分存储到不同的mysql节点上，这样每个节点上单表数据就会减少了，整个集群能保存的数据量就更多了
• 能增强抵御故障的能力
  我们再给MysQl节点配上冗余的备份节点，比如第一个MySQL节点挂掉了，它的备份节点就可以立即投入使用，这样抵御故障的能力就会被单节点好很多