这五个数据科学家和机器学习工程师油管博主

简单来说就是写入通过消息中间件来将同步转异步，进行前端削峰。而对于查询则进行内容缓存或创建二级索引，提升查询效率。

对于查询本身又包括了偏结构化数据查询和处理，类似采用Redis库或Memcached进行缓存;而对于非结构化数据，类似消息报文，日志等采用Solr或ElasticSearch构建二级索引并实现全文检索能力。

当面临大量的数据写入操作类操作的时候，单个Master节点往往性能很难支撑住，这个时候采用类似RabbitMQ，RocketMQ，Kafka等消息中间件来进行异步销峰处理就是必要的。这个异步实际上涉及到两个层面的异步。

其一是对于发短信，记录日志，启流程等接口服务异步。其二是对长耗时写入操作异步，先反馈用户请求收到，处理完再通知用户拿结果。

而对于查询操作，前面谈到的并发查询可以进行集群负载。

但是对于大数据量表，比如上亿记录的大表模糊查询，这块就必须进行二级索引。对这种大的数据表的查询即使没有并发查询，如果不进行二级索引，查询效率和响应速度仍然很慢。

对半结构化信息启用分布式存储
 

在上图这种逻辑部署架构下，基本就可以同时满足高可靠和高性能两个方面的需求。但是从上面架构部署可以看到，备节点的主和从都处于一种热备无法实际提供能力状态。

是否可以将所有Slave挂到一个Master上?

如果这样设计，那么当主Master出现故障的时候，就需要对多个Slave节点进行自动化漂移。这一方面是整体实现比较复杂，另外就是可靠性也不如上面这种架构。

对数据库性能扩展的思考

首先来看前面架构本身的一些潜在问题点：

第一就是CUD操作仍然是单节点提供能力。对于读操作占大部分场景的，基本可以通过双主+读写分离集群实现很好的性能扩展。但是如果CUD操作频繁仍然可能出现性能问题。

其次，数据库性能问题一般分为两个层面，其一就是大并发请求下的性能，这个可以通过集群负载均衡去解决，其二是单个请求访问大数据库表模糊查询性能，这个是服务通过负载去解决的。

也就是说上面的设计，在大并发的CUD操作，对大数据表的关联查询或模糊查询操作仍然可能出现明显的性能问题。

如何来解决这个问题?
 

同时在拆分后虽然引入了各种跨库查询，分布式事务等问题，但是实际很多跨库操作，复制的数据处理计算都不在数据库里面完成，数据库更多的是提供单纯的CRUD类操作接口，这本身也是提升数据库性能的一个关键。

如果采用Mysql数据库。

要满足高可靠性，你可以采用Dual-Master双主架构，即两个主节点双活，但是仅一个节点提供数据库接口能力，另外一个节点实时同步数据库日志，作为备节点。当主节点出现故障的时候，备节点自动转变为主节点服务。

简单的双主架构两节点间安装代理，通过Binlog日志复制，上层通过类似Haproxy+Keepalive实现通过的VIP浮动IP提供和心跳监测。

可以看到双主架构更多的是为高可靠服务。

如果要满足高性能，常采用的是读写分离集群。即1个主节点承担读写操作，多个从节点承担读操作。从节点仍然是通过Binlog日志进行主节点信息同步。当有数据访问请求进入的时候，前端Proxy可以自动分析是CUD类请求，还是R读请求，以进行请求的路由转发。

当我们进行订单新增操作的时候，当新增成功的时候需要快速的刷新当前订单列表界面，第二次的刷新本身是读操作，但是和前面的写绑定很紧，实际上不太适合从Slave节点读取数据的。这个时候可以在进行Sql调用的时候明确指定是否仍然从主节点获取数据。

当然，大部分时候可能需要两者结合，既提供足够的高可靠性，又提供足够的高性能。因此Mysql集群在搭建的时候既需要进行双主设置，又需要进行多个从节点设置。

（编辑：周口站长网）

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