标签：主主 text marks --- state mysql nodes type id
前言：
为什么要对mysql做优化？
因为数据都来源于数据库，如果数据库慢了，无论是多线程、各种识别模式优化还是很慢，因为查sql就很慢。
官方说法：单表2000万数据，增删改查就到达瓶颈了。所以为了保证查询效率，得让每张表的大小得到控制。
Mysql架构：
实际生产过程中，查询业务更多，增删改中也包含查询。
双主架构：
两个主都负责增删改查。
如果有1000w个请求，就会让1000w分流，给两个主各分500w，且两主之间做数据同步。即两主数据库增删改查后数据同步，查询随便走哪个。
- 实现方式：
- mysql官方支持两主架构，在搭建二主架构的时候，修改mysql配置文件，数据就能自动同步
- 双写：代码中写完主1，再写主2
- 双主架构一般不怎么用：双主架构只是将负载进行了均分，如果更新频繁的话，这两个服务器压力都会很大。
主从架构
主节点负责增删改，从节点负责查。可以将大量请求的查询操作均摊到多个服务器里。
- 实现方式
- mysql官方支持主从架构，在主服务器配置从服务器的ip端口...，主服务器一旦有增删改操作，会自动同步到从节点。
- 从节点只允许查，别的操作会报错。
- 主从数据同步原理：监听binlog日志
- 优点:
- 一主多从：主节点负责增删改，从节点负责查。这种方式使用最多，不仅限于高并发，许多生产环境都会采用。如果在双主架构中，一个主节点宕机，另一个主节点也就宕了。但在主从架构中，有一个“选举制“，如果主节点宕机，从节点会自动晋升到主，代替原来主节点的工作（高可用），当宕机主节点重新启用时，他就变成了从。
- ===>保证服务高可用，避免单点故障，同时提高了性能。
- 缺点：
- 0、在分布式系统中，要么满足CP，要么满足AP。
- CAP理论：Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容忍性)； 如果要实现CP，就不能保证高可用，如果要实现AP就不能保证一致性。三者之间不能同时存在。
- 1、不能满足强一致性，如果主节点刚新增一条数据，但还未向从库同步，他就宕机了，从节点晋升为主节点后则会丢失这条数据。
- ==>解决：主节点入库时可以选择入库方式：a、主节点落库以后，不管从节点有没有同步，直接返回sql执行成功；b、主节点落库以后，所有从节点都完成同步才返回sql执行成功，当有一个从节点落库失败返回执行失败。（b策略可以满足一致性，但很慢）
- 2、有可能造成同步延时问题。
- 例如：新下单立马去查看列表，由于主从库还未同步 有可能没有订单记录。
- 例如：退款后立马查看订单状态还是购买成功状态，由于主库还未向从库同步。
- ==>解决：可以采用分布式全局锁的形式。 退完款在redis里边放一个锁，等到查询的时候发现退款是false，但redis内是有锁的，我们就知道用户已退款只是从库还未同步，就可以给用户返回“后台正在处理，请稍后重试！”。（redis没有事务）
主从架构只能缓解查询压力，但解决不了表大小的问题。
于是 ----> 拆表 ----> 5000w数据 ----> 3个2000w ----> 多主多从
怎么实现？：程序在入库或查询之前先计算出来应该走哪个库。如果走的是主1库，那么我的增删改就在主1库查询。
如果数据量更大，例如有10亿，拆成10个库有点不现实。所以采用“冷热分离”。
虽然我有10亿数据，比如订单表、聊天记录，但两年前的订单或者两年前的聊天记录 都不会看，所以使用冷热数据分离。
如果冷数据占比较多，那么冷数据就单独存起来。热点数据还是用mysql（主从...）。冷数据查的慢点没关系。
如果订单表不存在关联表关系，只存放订单的创建时间、购买的什么商品、单价、交易时间.....，就可以无脑把数据扔到es中。
对于es来说，在海量数据下，查询性能较mysql高得多。在官方文档里描述，1PB的数据，秒级响应。1PB=1024TB=1024*1024GB。但内存占得多。
但这么说es并不能替代mysql，mysql有一个天生的优势就是事务。mysql是关系型数据库，es更像是一种单表查询。
标签：主主,
text,
marks,
---,
state,
mysql,
nodes,
type,
id
From： https://www.cnblogs.com/nliu/p/17669653.html