这是我参与8月更文挑战的第21天，活动详情查看： 8月更文挑战
既然系统用上了分布式架构，那肯定客户端的访问量也不会小，伴随着每次访问，都会进行数据的读写操作，前端采用了负载均衡等一系列操作可以抗住压力，这个时候就把压力一到了数据库上面，数据库对于软件来说，我比较喜欢比作心脏。对于网站操作的话，大多数情况都是读多写少，我们可以基于这种情况，将操作数据库进行读写分离，既然读多写少的话，那就多怎这个读库。
这样的话，通过数据库的主从同步机制，将主库的数据同步到从库，MySQL对于主从同步支持的比较完善；因为需要将读写路由到不同的数据库上面，这里就采用DB中间件来做，例如MyCat，会根据我们配置的规则，路由到不同的库上面去。这种方案也存在一定的问题，主从同步延迟问题，从库延迟主库时间久，在从库上面就读取不到主库写入的数据，就会影响业务的逻辑。
读取从库的话，如果需要搜索数据的话，数据量比较大，对于搜索时，数据的压力就比较大，这个时候就需要引入搜索引擎，构建数据的搜索索引，根据搜索到的数据然后去从库查询具体的数据信息。
在这里可以将搜索引擎比作一个从库，只是这个从库比较特殊，只提供数据检索的功能，当需要搜索数据时，这个时候就走搜索引擎搜索出数据，引入了搜索引擎这样的话，可以加快搜索时间，也会减少从库数据库的压力。搜索引擎对关键是构建索引，上图画的搜索引擎同步数据直接从主库同步不是很对，基本上采用的是将主库的操作数据转换为binlog，然后将binlog日志发送到MQ，需要接入数据的地方就监听MQ，然后对数据进行操作，例如同步到大数据都是这样搞的。
在现在稍微有点规模的网站都会用到数据缓存，目的也是缓解数据库的压力，缓存系统主要保存的键值对，应用程序将热点写入缓存，这样每次查询的时候写从缓存中获取，如果缓存获取到就直接返回给客户端，如果没有就从数据库中查询，然后将数据存入缓存，然后在把数据返回给客户端，引入缓存后，就会考虑缓存与数据库数据一致性问题、缓存雪崩问题、缓存击穿等问题，这些相对现在都有比较好的方案可以避免一定概率发生。现在用的比较多的缓存有：Redis、mongoDB
当数据量达到一定程度后，就会考虑水平拆分，将业务按照模块来拆分到不同的数据库存储，当不能够在拆分的时候，单表存入数据比较大时，就会对单表的存储进行垂直拆分，按照一定的规则对存储数据进行分表存储，因为采用了数据库分库分表操作。当我们需要做财务报表的时候，就比较麻烦了，大数据这个时候就闪亮登场了。
看上面的简易图，就可以看出将分库分表的数据整个到大数据中，然后在通过大数据的生态组件进行报表，大数据出报表的话，实时性比较差，很难做到数据实时同步，基本上都是T+1，所以财务报表很多时候都是T+1。
对于实时性比较高的情况，就需要分布式数据库来存储数据，现在开源的有TiDB，用的还比较多，性能也比较稳定，开源社区也比较活跃。
