forked from youngyangyang04/TechCPP
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request youngyangyang04#55 from alu234/master
update:12 articles
- Loading branch information
Showing
14 changed files
with
94 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
1. **基于内存存储**:Redis将数据存储在内存中,相比于传统数据库需要从磁盘读写数据,内存访问速度更快,能够大大提高读写性能。 | ||
2. **非阻塞IO**:Redis使用了多路复用技术,采用非阻塞IO模型,能够同时处理多个连接请求,充分利用系统资源,提高并发处理能力。 | ||
3. **单线程模型**:虽然Redis是单线程的,但它通过事件驱动、异步非阻塞的方式处理请求,减少了线程切换和同步开销,降低了整体的耗时。 | ||
4. **精简的数据结构**:Redis使用了简洁高效的数据结构,如字符串、哈希表、列表等,这些数据结构底层实现经过优化,能够快速执行各种操作。 | ||
5. **数据分区和持久化**:Redis支持数据分区和持久化机制,可以水平扩展并保证数据不丢失,提高了系统的可靠性和性能。 | ||
6. **内置命令优化**:Redis内置了丰富的命令集合,并对常用命令进行了优化,保证了命令的执行效率。 | ||
7. **高效的网络通信**:Redis使用自定义的协议与客户端通信,协议简单轻量,减少了通信开销,加快了数据传输速度。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
1. 主从复制:Redis主从复制是指将一个Redis实例(主节点)的数据复制到多个从节点的过程。主节点负责写操作和读操作的处理,从节点负责接收主节点发送过来的数据并进行复制,从而实现数据备份和读取负载均衡。主从复制提供了数据冗余和故障恢复功能。 | ||
2. 哨兵:Redis Sentinel是一种监控系统,用于监视Redis主从复制架构中的各个节点,并在主节点失效时自动将其中一个从节点升级为新的主节点,以保证系统的高可用性。哨兵系统保持对所有节点的监控,并在需要时执行自动故障转移,确保系统稳定运行。 | ||
3. 集群:Redis集群是一种分布式部署方式,通过将数据分片存储在不同的节点上,实现了数据水平扩展,提高了系统的性能和容量。Redis集群采用哈希槽分配数据的方式,每个节点负责管理一部分哈希槽,可以动态扩展和收缩节点。集群还提供了数据复制和故障转移等功能,确保数据的可靠性和高可用性。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
Redis和Memcached是两种常见的内存缓存系统,它们在功能、性能和应用场景上有一些不同之处。以下是Redis和Memcached的主要区别: | ||
|
||
1. **数据结构支持**: | ||
- Redis支持更丰富的数据结构(如字符串、哈希、列表、集合、有序集合等),可以进行更复杂的数据操作和计算。 | ||
- Memcached只支持简单的key-value数据结构,适合存储简单的数值或文本数据。 | ||
2. **持久化**: | ||
- Redis支持持久化机制,可以将数据存储到磁盘中,保证数据不会因服务重启而丢失。同时也支持RDB快照和AOF日志等方式。 | ||
- Memcached不支持持久化,数据仅存在于内存中,服务重启后数据会全部丢失。 | ||
3. **数据淘汰策略**: | ||
- Redis支持多种数据淘汰策略,如LRU(最近最少使用)、TTL(过期时间)等,可以根据需求自定义数据淘汰规则。 | ||
- Memcached采用LRU淘汰策略,当内存不足时会淘汰访问时间最早的数据。 | ||
4. **分布式支持**: | ||
- Redis可以通过集群模式实现分布式缓存,支持数据分片和故障转移,提高了可扩展性和容错性。 | ||
- Memcached天生就是分布式的,可以通过添加新的节点来扩展缓存容量,但没有内置的分片和故障转移机制。 | ||
5. **数据复杂度**: | ||
- Redis适用于需要复杂数据类型和数据结构的场景,如存储对象、列表、计数器等。 | ||
- Memcached适用于简单的键值对存储,对于复杂数据结构的处理能力较弱。 | ||
6. **性能比较**: | ||
- 在读取和写入大量数据时,Memcached通常比Redis性能略好,因为它专注于快速的缓存读写操作。 | ||
- 对于复杂数据结构和计算密集型任务,Redis通常表现更优秀,因为其丰富的数据结构和功能。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
Redis的BigKey问题是指在Redis中存在占用大量内存空间的key,会导致Redis内存占用过高、影响性能甚至引发Redis服务宕机等问题。以下是一些解决Redis BigKey问题的方法: | ||
|
||
1. **监控和排查**:定期监控Redis内存使用情况,通过Redis命令`memory usage`可以查看各个key的内存占用情况,及时发现潜在的BigKey。 | ||
2. **拆分大key**:对于已经存在的BigKey,可以考虑将其拆分成多个小key,根据业务需求来设计合适的数据结构,将大key的数据分散存储在多个小key中,减少单个key的内存占用。 | ||
3. **使用Hash数据结构**:对于存储大量字段的数据,可以使用Redis的Hash数据结构来代替单个key,将大key拆分为多个field存储在Hash中,降低内存占用。 | ||
4. **压缩数据**:对于存储文本类型数据的key,可以考虑对数据进行压缩(如GZIP压缩),减少内存占用。需要注意的是,在每次读写操作时都需要进行解压缩,可能会增加CPU负载。 | ||
5. **设置过期时间**:对于临时性数据或者不常访问的大key,可以设置过期时间,当数据过期后自动释放内存,避免长时间占用内存。 | ||
6. **持久化数据**:将不常访问的大key数据持久化到磁盘,比如使用Redis的RDB快照或者AOF持久化功能,将数据从内存释放出来,减轻内存压力。 | ||
7. **限制数据大小**:在应用层面限制数据写入的大小,避免写入过大的数据导致BigKey问题,可以通过配置Redis参数`hash-max-ziplist-value`和`hash-max-ziplist-entries`等来限制Hash数据结构的大小。 |
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
Redis缓存击穿是指在高并发情况下,一个不存在的key被大量请求同时访问,导致这些请求绕过缓存直接查询数据库,从而造成数据库压力剧增。以下是一些解决Redis缓存击穿问题的方法: | ||
|
||
1. **设置热点数据预加载**:在系统启动或者运行期间,提前将热点数据加载到缓存中,即使某个key暂时失效也能保证缓存命中率。通过定期刷新热点数据,确保缓存中始终存在热门数据。 | ||
2. **使用互斥锁**:在查询缓存之前,可以使用分布式锁或者互斥锁来控制对数据库的访问,避免多个线程同时去查询数据库。只有一个线程去查询数据库,其他线程等待其返回结果后再从缓存获取数据。 | ||
3. **缓存穿透处理**:当缓存查询不到数据时,可以考虑返回默认值、空值或者错误提示作为缓存对象,避免频繁查询数据库。同时,可以设置较短的过期时间,以便尽快从数据库获取最新数据更新缓存。 | ||
4. **熔断策略**:实施熔断机制来保护后端服务,当大量请求同时访问数据库时,可以暂时关闭数据库访问,返回错误信息或者降级处理,防止数据库崩溃。 | ||
5. **使用一致性哈希算法**:通过一致性哈希算法将请求均匀地分布到不同的节点上,避免某个节点集中承载大量请求,减少单点压力。 | ||
6. **提升缓存容量和性能**:根据业务需求和流量情况,合理调整Redis的内存容量和性能配置,确保能够承载更高的并发请求,提高缓存命中率。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
1. **布隆过滤器**:使用布隆过滤器在缓存层进行数据预先过滤,将可能存在的数据放入布隆过滤器中。当请求到来时,先根据布隆过滤器判断是否存在于缓存中,避免直接查询数据库。 | ||
2. **空值缓存**:当查询结果为空时,也将该空结果进行缓存,设置较短的过期时间。这样下次再有相同的查询请求时,就可以从缓存中获取空结果,减少对数据库的频繁查询。 | ||
3. **缓存雪崩处理**:设置不同的过期时间或者使用分布式锁等机制,避免大量缓存同时失效导致的缓存雪崩问题,提高系统的稳定性。 | ||
4. **热点数据预热**:在系统启动或者运行期间,提前加载热门数据到缓存中,避免冷启动时出现缓存穿透的情况。 | ||
5. **限流控制**:对请求进行频率限制,通过限流算法(如令牌桶、漏桶等)控制请求的访问频率,防止恶意请求导致缓存穿透。 | ||
6. **使用缓存标记:在缓存中存储数据是否存在的标记,如果查询结果为空,也将此标记缓存起来,下次查询时先检查标记,若不存在则直接返回空结果。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
Redis缓存雪崩是指在某个时间点,大量缓存同时失效或者被清除,导致大量请求直接访问数据库或者后端服务,造成系统压力剧增,甚至导致系统瘫痪。以下是一些解决Redis缓存雪崩问题的方法: | ||
|
||
1. **缓存数据过期时间随机性**:设置缓存数据的过期时间时,可以在原有过期时间基础上加上一个随机值,避免大量缓存同时失效。比如对于同一种类型的缓存数据,可以设置一个范围在原定过期时间上波动的随机值。 | ||
2. **二级缓存策略**:使用多级缓存架构,例如引入本地缓存(比如内存)作为一级缓存,在Redis之前缓存一层,当Redis中的缓存发生雪崩时,本地缓存可以作为备用,减轻数据库负载。 | ||
3. **缓存数据自动刷新**:在缓存数据即将过期时,异步或者定时任务重新加载缓存数据,保证缓存数据的稳定性。这样可以避免大规模同时失效,减少缓存雪崩的可能性。 | ||
4. **限流控制和熔断降级**:在缓存雪崩发生时,实施限流控制,通过限制请求的并发数量或者调整查询频率等方式来平滑处理请求,避免一次性压垮数据库。同时,可以考虑实施熔断降级策略,暂时关闭部分功能或者返回缓存响应较慢的提示信息,降低系统的压力。 | ||
5. **监控报警系统**:建立完善的监控系统,实时监测缓存状态和请求量,设置预警规则,及时发现异常情况并采取相应的应对措施,防止缓存雪崩的发生。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
一致性哈希是一种解决分布式系统中数据分片和负载均衡的算法。它通过将数据映射到一个固定范围的圆环上,然后根据数据的键值在圆环上寻找最近的节点来确定数据存储的位置,从而实现动态扩展和节点失效时的平滑数据迁移。 | ||
|
||
Redis集群之所以不用一致性哈希算法,主要有以下几个原因: | ||
|
||
1. Redis Cluster采用哈希槽分配数据:Redis集群将所有数据划分为16384个哈希槽,每个节点负责管理其中的一部分哈希槽,数据的位置由哈希槽来确定。这种方式简化了数据定位和节点管理,避免了传统一致性哈希算法中需要维护虚拟节点、一致性哈希环等复杂逻辑。 | ||
2. Redis Cluster提供内置的故障检测和自动迁移功能:Redis集群具有自动故障检测和节点替换的能力,当节点失效时可以自动将其槽位重新分配给其他可用节点,确保数据的可靠性和高可用性。这种自动化的机制大大简化了集群的管理和维护。 | ||
3. Redis Cluster支持节点间的无中心化通信:Redis集群中的各个节点都可以相互通信,而不依赖于单个中心节点进行协调。这样可以降低系统的单点故障风险,提高了系统的稳定性和容错能力。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
Redis支持事务,可以通过MULTI、EXEC、DISCARD和WATCH等命令实现简单的事务操作。在Redis事务中,一组命令被原子性地执行,要么全部成功,要么全部失败,保证了数据的一致性。然而,Redis的事务并不是严格意义上的ACID事务,因为它缺少隔离性和持久性。因此,在需要强一致性和高隔离性的场景下,建议考虑使用关系型数据库等支持ACID事务的解决方案。 | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
1. 同步复制:使用同步复制可以确保数据在主节点写入后立即被复制到所有从节点,从而减少数据丢失的可能性。虽然同步复制会增加写入延迟,但可以提高数据的可靠性。 | ||
2. 持久化策略:配置Redis集群的持久化机制,将数据写入磁盘,以防止数据在节点故障时丢失。可以选择使用RDB快照、AOF日志或者混合持久化方式来保护数据。 | ||
3. 监控和警报系统:建立监控系统,实时监测Redis集群的健康状态,包括节点的负载情况、延迟情况等。设置警报规则,当发生异常情况时及时通知管理员进行处理,避免数据丢失。 | ||
4. 集群配置和维护:合理配置Redis集群的参数,包括超时设置、最大连接数、最大内存限制等,以避免因配置不当导致的性能问题和数据丢失。定期检查集群的状态,并及时更新补丁和升级版本,以提高系统的稳定性和安全性。 | ||
5. 避免集群脑裂(Split-Brain):集群脑裂是指网络分区导致集群中的节点无法互相通信,从而出现数据不一致的情况。为避免集群脑裂,可以使用哨兵系统对集群进行监控和自动故障转移,保证集群中只有一个主节点对外提供服务。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
1. **读写分离**:将读写操作分离到不同的数据库实例中,读操作直接访问缓存以提高性能,写操作同时更新数据库和缓存。这样可以避免脏数据出现在缓存中。 | ||
2. **缓存穿透处理**:当缓存查询不到数据时,可以返回默认值、空值或错误提示作为缓存对象,同时查询数据库并将结果更新到缓存中。这样可以避免因缓存失效引起大量请求直接访问数据库。 | ||
3. **双写策略**:在更新数据库的同时,也更新缓存。确保数据库和缓存中的数据始终保持一致。可以使用事务来保证两者操作的原子性。 | ||
4. **缓存更新策略**:采用主动刷新或者定时刷新缓存的方式,使得缓存中的数据与数据库中的数据保持一致。可以根据业务需求选择合适的更新策略,比如定时刷新、异步刷新等。 | ||
5. **缓存失效处理**:当数据库中的数据发生变化时,及时使缓存失效,下次请求访问时重新从数据库获取最新数据。可以通过监听数据库的变更事件,自动使缓存失效。 | ||
6. **版本控制**:为缓存中的数据引入版本号,每次数据更新时更新版本号。在读取数据时,先比较版本号是否一致,不一致则重新从数据库获取数据并更新缓存。 | ||
7. **缓存锁**:在并发情况下,给涉及缓存和数据库的操作加锁,确保只有一个线程能够进行操作,防止脏数据的产生。 |