单点故障，MySQL主从复制能完美解决数据库的单点问题吗为什么

没有完美的解决方案单点故障。只有合适的解决方案。

当使用主从时，实际已经放弃了强一致性了。(既然题主只问单点问题，就不考虑访问量问题。即假设主从复制完全能支撑目前的系统访问。)

一般数据库主从设置：

主库可读可写

从库只读即系统既可以从主库获取数据，也可以从从库获取数据。数据写入主库后，自动同步到从库。

这构成了一个简单的分布式系统。根据cap定理，只能三选一。主从之间是最终一致，如果强一致，不但不会提高系统可用性，反而降低了系统可用性。

我们看上面的主从结构可能会出现哪些问题：

系统写入主库，再从主库查询。这就是个单点数据库，没有什么影响。

系统写入主库，再从从库查：- 如果数据已经同步，则没有影响

- 如果数据还未同步，则查询的是老数据

- 如果同步出现了问题，则主从断开。如果系统无法感知，则查询到的可能一直是老数据。这里就需要对同步进行监控，当同步出现问题时，及时处理

主库挂掉。从库需要及时感知，并替换主库。同时需要再通知运维人员处理，否则又变成了单点。

从库挂掉。主库数据无法同步到从库。同样需要及时通知处理

如果主从切换自动化，那单点故障的概率也只是降低50%而已（主库或备库挂掉没人恢复的话）。

服务器宕机几乎是一种比较常见的情况，它发生的原因有很多种，而且各种条件都很复杂，不过都达成了相同的效果，就是服务器无法再为用户处理数据了。

我就稍微列举一下通常服务器宕机可能得情况。

1.系统错误

这种情况发生得一般最常见，由于用户的错误设置，或者是一些软件的冲突，数据的损失，以及一些硬件的原因，导致服务器系统无法正常运行。比如防火墙的错误设置，引起外网无法连接。

2.服务器超载

由于程序运行，或者中毒的情况下，导致服务器磁盘读写，CPU，内存满载，就会引起系统崩溃自动重启。这种情况出了正常使用，也会在被网络攻击的时候出现，比如CC流量攻击。

3.机房空路由

这种情况常见于被DDOS攻击，一般的机房都会选择在达到一定量的时候，解除IP与服务器的绑定，导致服务器无法请求和访问，只能等待一定时间后自动恢复。

最后，做好服务器的安全防护比如cdn等，以及做好资源的分配，程序的限制等很重要。毕竟数据是无价，服务的稳定也是用户维持的关键。

ES 基础ES 集群ES 集群上业务优化一、ES 基础

ES 的安装下载，网上一大片，我这边不在重复。可以看看我以前做的小笔记：

Spring Boot 2.0 M7 整合 ES 5 、Kibana 和 X-pack

其中 ES 三大要素：

文档（Document）文档，在面向对象观念就是一个对象。在 ES 里面，是一个大 JSON 对象，是指定了唯一 ID 的最底层或者根对象。文档的位置由 _index、_type 和 _id 唯一标识。文档元数据：

_index ：文档在哪存放_type ： 文档表示的对象类别_id ：文档唯一标识索引（Index）索引，用于区分文档成组，即分到一组的文档集合。索引，用于存储文档和使文档可被搜索。比如项目索引命名为 project ，交易索引命名为 trade 等。

类型（Type）类型，用于区分索引中的文档，即在索引中对数据逻辑分区。比如设计项目分为 ui 、 ux 这些类型。可以放在该类目进行区分。但一般操作，很少用到这么复杂的。

可见， _index 索引的重要性。避免某个索引存储不相关的数据。

二、ES 集群

ES 集群搭建，文章很多。我这边也不一一列举了。先看 ES 集群分布式图

集群（Cluster）

跟服务器集群类似，多个 ElasticSearch 运行实例（节点 Node）的组合体是 ElasticSearch 集群。

ElasticSearch 是天然分布式的，可以通过水平扩容为集群添加更多节点。

ElasticSearch 集群是去中心化的，只有一个主节点（Master）。而且主节点是动态选举，因此不会出现单点故障。

那节点是什么？

节点（Node）

上面说过，一个 ElasticSearch 运行实例就是节点。任何节点都可以被选举成为主节点。主节点负责集群内所以变更，比如文档的增加、删除等。所以集群不会因为主节点流量的增大成为瓶颈。因为任何节点都会成为主节点。

如图，P1 P2 P0 是节点内的主分片，其他 R 是副分片。

那分片是什么？

分片（Shard）

分片，是 ES 节点中最小的工作单元。分片仅保存全部数据的一部分。分片包括主分片和副分片，主分片是副分片的拷贝。主分片和副分片基本没有大的区别。

如果是全文搜索，会查询到每个分片，然后将每个分片的结果进行全局地收集，并处理返回。

举个例子：比如新建了一个索引 project , 存储项目相关的数据。那具体的某个 project A 的数据会被切分，存储在不同的分片上。那么根据 project A 的 _id 如何路由到具体的分片上呢？

分片的路由公式是这样的：

hash 函数生成数字，经过取余算法得到余数。余数就是分片的位置。routing 是可变值，支持自定义。默认文档 _idnumber_of_primary_shards 主分片的数量三、ES 集群上业务优化

倘若如果刚刚那个例子，一个索引 project , 存储项目相关的数据。项目的数量级越来越大，亿量级，万亿量级。那一个大索引的查询啥的都会出现瓶颈。这时候该怎么优化呢？

这时候是不是想到了，一句常说的：空间换时间。这时候是不是也想到了，MySQL 分库

所以大索引的拆分，也不是很难。类似分片的路由规则，根据具体业务指定即可。

这里，我们可以定义 1000 个索引，分别名为 project_1、project_2、project_3…

然后在 ES 集群上面架一层简单的 proxy 。里面核心的业务路由规则可以这样：

project_id 项目自增 IDindex_id 得出来的索引对应的 ID总结一张图：

ES proxy 层：做总索引和真正分索引的映射ES 索引配置管理：做索引与业务的映射ES 集群：就是上面讲的