mirror of
https://gitee.com/52itstyle/spring-boot-seckill.git
synced 2025-12-30 10:22:26 +00:00
更新 Redis_hot.md
This commit is contained in:
@@ -92,3 +92,48 @@ slaveof host port 命令来让一个服务器成为另一个服务器的从服
|
||||
- 随着负载不断上升,主服务器可能无法很快地更新所有从服务器
|
||||
- 重新连接和重新同步从服务器将导致系统超载
|
||||
- 中间层的服务器是最上层服务器的从服务器,又是最下层服务器的主服务器
|
||||
|
||||
|
||||
### 6)redis 主服务器 故障 处理
|
||||
|
||||
当主服务器出现故障时,Redis 常用的做法是新开一台服务器作为主服务器,具体步骤如下:假设 A 为主服务器,B 为从服务器,当 A 出现故障时,让 B 生成一个快照文件,将快照文件发送给 C,并让 C 恢复快照文件的数据。最后,让 B 成为 C 的从服务器。
|
||||
|
||||
### 7)分片 集群 读并发
|
||||
|
||||
数据划分为多个部分,可以将数据存储到多台机器里,作用:负载均衡、线性级别的性能提升
|
||||
|
||||
### 8)分片方式:
|
||||
|
||||
客户端代码分片
|
||||
|
||||
- Redis Sharding,对Redis数据的key进行hash,相同的key到相同的节点上
|
||||
- 一致性哈希算法
|
||||
- 代理服务器分片 轮询round-bin
|
||||
|
||||
### 9)redis与数据库的同步 数据一致
|
||||
|
||||
- 一致性要求高场景,实时同步方案,即查询redis,若查询不到再从DB查询,保存到redis;
|
||||
|
||||
- 更新redis时,先更新数据库,再将redis内容设置为过期(建议不要去更新缓存内容,直接设置缓存过期),再用ZINCRBY增量修正redis数据
|
||||
|
||||
- 并发程度高的,采用异步队列的方式,采用kafka等消息中间件处理消息生产和消费
|
||||
|
||||
- 阿里的同步工具canal,实现方式是模拟mysql slave和master的同步机制,监控DB bitlog的日志更新来触发redis的更新,解放程序员双手,减少工作量
|
||||
|
||||
- 利用mysql触发器的API进行编程,c/c++语言实现,学习成本高。
|
||||
|
||||
|
||||
### 10)热数据与Mysql的同步编码实现 数据库上锁
|
||||
|
||||
热点数据(经常会被查询,但是不经常被修改或者删除的数据),首选是使用redis缓存
|
||||
|
||||
用spring的AOP来构建redis缓存的自动生产和清除,过程如下:
|
||||
|
||||
- Select 数据库前查询redis,有的话使用redis数据,放弃select 数据库,没有的话,select 数据库,然后将数据插入redis
|
||||
- update或者delete 数据库数据
|
||||
- 高并发的情况下:先对数据库加锁,再删除redis
|
||||
- 查询redis是否存在该数据,若存在则先对数据库加行锁,再删除redis,再update或者delete数据库中数据
|
||||
- update或者delete redis,先更新数据库,再将redis内容设置为过期(建议不要去更新缓存内容,直接设置缓存过期)
|
||||
|
||||
|
||||
出错场景:update先删掉了redis中的该数据,这时另一个线程执行查询,发现redis中没有,瞬间执行了查询SQL,并且插入到redis
|
||||
|
||||
Reference in New Issue
Block a user