Redis
和MySQL
搭配使用,当有请求时,首先会从缓存中进行查询,如果存在就直接取出。如果不存在在访问数据库,这样就提升了读取效率
,也减少了后端数据库的访问压力
。读多写少
,对于数据库的读取数据压力比较大,所以可以采用数据库集群的方案
,做主从架构
、进行读写分离
,同样可以提升数据库并发处理能力。读写分离
:由于读多写少
,master主库充当写库
,salve从库充当读库
,当主库更新时,会自动将数据复制到从库中,而客户端读取数据时,会从从库中进行读取,面对读多写少,采用读写分离
,在实现高并发的同时,还能对从服务器进行负载均衡
,让不同的读请求按照相应策略均匀的分发到不同的从服务器上,而且减少锁表
的影响,主库写锁时,从库依旧可以读。
数据备份
:通过主从复制将主库上的数据复制到了从库上,相当于一种热备份机制
,也就是在主库正常运行的情况下的备份,不会影响到服务高可用性
:数据库备份实际上是一种冗余的机制
,通过冗余的方式可以换取数据库的高可用性,也就是当服务器出现故障
或宕机
情况下们可以切换
到从服务器上,保证服务的正常运行。Slave
会从 Master
读取 binlog
来进行数据同步。但是也可能出现主库将数据同步到从库需要500ms,而此时主库刚写完,就要从读库读(假设读200ms),此时就会出现延迟问题,这就需要后面的方法。实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中,会基于 3 个线程 来操作,一个主库线程,两个从库线程
复制三步骤
具体详细过程如下:
复制的问题
延时
从库是不是越多越好?
MySQL 主从复制还有哪些模型?
主从延迟
不一致性
问题。主从延迟问题原因
主备延迟最直接的表现是,从库消费中继日志(relay log)的速度,比主库生产binlog的速度要慢
如何减少主从延迟
减少批量操作
提高从库机器的配置
,减少主库写binlog和从库读binlog的效率差 短的链路
,提升端口带宽如何解决一致性问题
- 如果操作的数据存储在同一个数据库中,那么对数据进行更新的时候,可以对记录加写锁,这样在读取的时候就不会发生数据不一致的情况。但这时从库的作用就是
备份
,并没有起到读写分离
,分担主库读压力
的作用。读写分离情况下,解决主从同步中数据不一致的问题, 就是解决主从之间 数据复制方式 的问题
方法 1:异步复制
方法 2:半同步复制
方法 3:组复制
- 首先我们将多个节点共同组成一个复制组,在 执行读写(RW)事务 的时候,需要通过一致性协议层(Consensus 层)的同意,也就是读写事务想要进行提交,必须要经过组里“大多数人”(对应 Node 节点)的同意,大多数指的是同意的节点数量需要大于 (N/2+1),这样才可以进行提交,而不是原发起方一个说了算。而针对 只读(RO)事务 则不需要经过组内同意,直接 COMMIT 即可。
- 在一个复制组内有多个节点组成,它们各自维护了自己的数据副本,并且在一致性协议层实现了原子消息和全局有序消息,从而保证组内数据的一致性。