AatZai的博客

摘要：本文以微博为例，详细解析社交Feed流场景的缓存架构设计。Feed流处理存在100-1000倍的读放大，后端通过多级缓存体系实现毫秒级响应：关注关系用Redis存储，Feed内容采用Memcached+Protocol Buffers，存在性判断使用自研的BloomFilter系统，计数服务采用优化的CounterService。特别介绍了三层Memcached架构（L1-Main-Backup）如何应对突发流量，以及数据读写策略。整套系统通过99%以上的缓存命中率支撑亿级用户的高并发访问，满足50-

摘要：本文介绍了海量计数场景下的缓存设计方案。针对微博等社交平台超高并发计数的需求，分析了传统缓存+DB和纯Redis方案的不足，提出了基于定制化Redis的计数服务系统。该系统采用内存Table与磁盘DDB结合的存储方式，通过紧凑存储、冷热分离、多级查询等优化手段，将内存占用降低至Redis的10%以下，查询性能提升3-5倍。系统支持单个key存储多个固定大小的计数，并采用特殊的分表、哈希算法和异常处理机制，有效解决了海量计数场景下的存储成本与性能瓶颈问题。

秒杀系统缓存设计摘要：秒杀活动具有瞬时高并发、业务简单但访问量大的特点。系统设计需遵循"上游拦截+缓存优先"原则：1）将静态资源部署至CDN；2）构建多级访问控制（按钮置灰、权限校验）；3）建立商品信息/库存专用缓存并进行预热；4）采用缓存代替DB完成核心交易流程；5）异步处理持久化操作。通过缓存体系实现请求过滤、快速响应和压力卸载，最终保障系统在高并发下的稳定性和用户体验。

微博分布式Redis服务系统采用多组件架构，包含无状态多租户Proxy、定制化存储wredis、配置中心configService和集群管理ClusterManager。Proxy通过业务端口区分请求，采用pipeline批量访问提升效率；wredis优化存储结构，去除key-slot映射节省20%空间，支持热升级和多种迁移方式。系统通过多IDC部署配置中心和公有云扩展应对流量洪峰，根据业务类型（缓存/存储）采用消息总线或主从复制实现数据同步。ClusterManager统一管理资源部署、监控报警和故障转移

本文探讨了分布式系统设计中CAP理论的实践与突破，以及BASE理论的应用。传统CAP理论的三选二模式存在局限性，实际应用中需要根据业务特点灵活调整。文章提出分区异常处理的三个步骤：感知分区、分区模式处理及数据修复同步。BASE理论强调基本可用、软状态和最终一致性，更适合现代分布式系统。在一致性保障方面，介绍了分布式事务（2PC/3PC/Paxos等）、主从复制和业务层消息总线三种方案，并以微博的多区数据一致性案例说明消息中间件的实践应用。这些方法在保证系统可用的同时，实现了数据的最终一致性。

摘要：CAP定理指出分布式系统无法同时满足一致性(C)、可用性(A)和分区容错性(P)三个要素。该理论由Eric Brewer提出，经证明成为分布式系统设计的核心原则。实际应用中通常需权衡选择：CA（单机系统）、CP（如金融系统优先保证一致性）或AP（如社交平台优先保证可用性）。但CAP理论存在理想化局限，现实中分区问题复杂，网络延迟、业务差异等导致不同场景需要灵活处理，并非简单的三选二。随着分布式系统发展，CAP理论需要结合业务特点进行针对性优化设计。

《Redis生产环境扩展优化实践》摘要：面对百万级QPS挑战，微博通过三大方向优化Redis：1）热升级方案，通过壳程序+动态库实现毫秒级版本更新；2）定制化数据结构，如longset提升大集合操作效率，改造计数存储实现冷热分离；3）完全增量复制机制，整合rdb+aof避免全量同步。同时构建独立集群管理体系，将存储与集群逻辑解耦，通过配置中心实现智能调度。这些优化使Redis在千亿级计数、TB级数据场景下仍保持高性能。

Redis集群提供了三种分布式方案：Client端分区、Proxy端分区和原生RedisCluster分区。Client端分区通过哈希算法直接映射数据到Redis节点，简单高效但扩展不便；Proxy端分区通过中间代理组件转发请求，业务解耦但性能有损耗；RedisCluster采用去中心化架构，通过slot分配和gossip协议实现动态扩缩容，支持在线迁移但存在阻塞风险。三种方案各有利弊，需根据业务场景选择最适合的集群方案。

Redis复制机制通过主从架构实现数据多副本存储，提升系统可用性和读性能。2.8版本引入psync支持增量复制，4.0版本优化为psync2，使用replid替代runid，并新增replid2记录历史主库ID，大幅减少全量复制场景。复制过程包括连接建立、鉴权、版本校验等步骤，主库根据从库上报的复制ID和偏移量决定全量或增量同步。全量复制需要传输RDB文件，资源消耗大；增量复制仅发送缓冲区的写指令，效率高但仍受缓冲区大小限制。该机制有效降低了主库负载和网络开销，但需合理配置复制缓冲区以避免频繁全量复制。

Redis 6.0引入多线程模型提升性能，主要改进点包括：1）新增IO线程负责并发处理请求读取、解析和响应回复；2）主线程仍单线程处理命令执行等核心操作。该方案可实现1-2倍性能提升，但仍存在明显局限：命令执行和事件触发仍由主线程串行处理，IO采用批处理模式导致请求相互等待，主线程自旋等待效率低下。若要实现更大性能突破，需将命令执行和事件处理也并行化，并优化多线程交互机制。相比Memcached原生支持的多线程架构，Redis当前方案仍显粗糙。

Redis引入BIO后台线程处理慢任务以避免阻塞主线程。BIO线程采用生产者-消费者模型，主线程生产任务放入队列，BIO线程消费执行。Redis启动时创建3个BIO线程分别处理文件关闭、AOF同步和延迟清理任务。任务处理流程包括：主线程提交任务并唤醒线程，BIO线程获取任务执行，完成后再次阻塞等待。该机制有效提升了Redis主线程的处理性能。

本文介绍了Redis数据恢复的三种持久化方案：RDB、AOF和混合持久化。RDB通过快照方式保存内存数据，具有文件小、恢复快的特点，但构建耗时且无法实时保存；AOF记录所有写操作，数据完整性高但文件冗余大、恢复慢；混合持久化结合二者优势，在RDB快照基础上追加增量命令，实现高效恢复和全量数据保存。文章详细分析了每种方案的触发机制、存储结构、优缺点及适用场景，建议根据业务需求选择合适的持久化策略，如混合持久化可兼顾数据完整性和恢复速度。

Redis内存淘汰策略详解：当内存超限(maxmemory)时，Redis提供8种淘汰策略(noeviction/volatile-lru/allkeys-lfu等)，通过maxmemory-policy配置。淘汰过程采用evictionPool机制，基于LRU/LFU/TTL算法从主字典或过期字典中采样评估key活跃度。支持同步/异步删除(通过lazyfree配置)，异步删除针对大value(元素>64的集合类型)。淘汰触发场景包括：1)定期serverCron任务(随机采样检查过期key)；2)命

Redis内部数据结构详解 Redis数据库采用16个redisDb结构存储数据，每个包含2个核心字典（主字典和过期字典）和3个辅助字典（阻塞、解除阻塞和监控）。所有数据类型都存储在redisObject结构中，包含类型、编码、LRU信息等字段。 核心数据结构包括： dict：哈希表实现，用于键值存储和集合类型 sds：动态字符串，二进制安全且高效 ziplist：紧凑内存结构，用于小规模哈希和有序集合 quicklist：链表+ziplist混合结构，优化列表存储 zskiplist：有序跳跃表，支持高效

摘要：本课时讲解Redis协议解析及处理流程。客户端请求命令首先存入querybuffer，超过1GB会报错关闭连接。协议解析根据首字符判断MULTIBULK或INLINE类型，解析后参数存入client的argc和argv。执行阶段，非quit指令会查找对应的redisCommand并执行proc函数，结果写入写缓冲并同步到AOF和从节点，同时更新统计信息。quit指令则直接返回OK并关闭连接。

上一课时，我们学习了 Redis 的系统架构，接下来的几个课时我将带你一起对这些模块和设计进行详细分析。首先，我将分析 Redis 的事件驱动模型。

摘要：本课时讲解Redis系统架构，包括事件处理机制、数据管理、功能扩展和系统扩展。事件处理采用ae事件驱动模型，支持IO多路复用；数据管理通过redisDB结构存储8种数据类型，并支持AOF和RDB持久化；功能扩展可通过ModuleSystem模块实现插件化开发；系统扩展方面改进了主从复制和集群功能，支持增量复制、数据迁移和在线扩容，提升系统稳定性和扩展性。

本课时介绍了Redis协议(RESP)的核心内容：1. 协议设计遵循简单实现、快速解析、可读性三大原则；2. 支持三种交互模式（Ping-Pong、管道、发布订阅）；3. 包含2种请求格式（内联命令和数组格式）和5种响应格式（简单字符串、错误、整数、字符串块、数组）；4. 协议分为16类，涵盖8种数据类型操作和8种系统功能；5. 对比了Java客户端Jedis和Redisson的特点及改进建议。课程还回顾了Redis的核心特性、数据类型及应用场景，为后续深入学习奠定基础。

本文介绍了Redis的8种核心数据类型及其应用场景：1. String字符串类型：二进制安全，支持数字存储，适用于缓存、计数器等场景。2. List列表类型：双向链表结构，适合消息队列、时间线存储。3. Set集合类型：无序唯一元素集合，适合好友列表、去重统计。4. Sorted Set有序集合：带score排序的集合，适合排行榜、范围查询。5. Hash哈希类型：键值对映射表，适合存储对象属性。6. Bitmap位图：二进制位操作，适合标记系统、用户标签。7. GEO地理位置：基于有序集合实现，支持位置查

Redis是一款高性能的内存键值数据库，支持多种数据结构类型。它采用单线程模型处理请求，基于epoll事件模型实现非阻塞I/O，避免了多线程竞争和上下文切换的开销。Redis既可以将数据存储在内存中，也支持持久化到磁盘，提供主从复制和集群分片功能来扩展容量。Redis作为缓存中间件时，最大的优势在于其丰富的数据类型支持，包括字符串、列表、集合等8种核心类型。

本文介绍了Twemproxy框架的核心架构、应用场景及扩展方案。Twemproxy是Twitter开源的缓存代理中间件，支持Memcached和Redis协议，通过一致性哈希、取模等算法实现后端资源分片访问。其单进程单线程架构采用epoll事件驱动、连接复用和零拷贝技术提升性能，QPS可达6-8万。文章详细解析了请求处理流程，并针对性能瓶颈、负载均衡、配置管理等不足，提出多进程改造、增加配置中心、支持主从访问等优化方案。通过扩展，Twemproxy能更好支持多层缓存架构和Redis主从读写分离，QPS可提升

本文探讨了大数据时代下Memcached面临的五大经典问题及解决方案。主要问题包括：1)单机内存容量不足；2)性能瓶颈导致QPS受限；3)连接数限制；4)硬件故障引发的雪崩效应；5)突发流量下的扩展难题。提出的解决方案包括：1)采用分拆缓存池策略，支持一致性哈希和哈希取模两种分布算法；2)构建Master-Slave二级架构，提升系统可用性；3)引入Master-Slave-L1三级架构，通过热点数据分层处理应对流量洪峰。这些方案有效解决了Memcached在大规模互联网系统中的容量、性能和稳定性问题，特别

本文系统介绍了Memcached协议的核心内容，重点分析了三种错误响应机制（ERROR、CLIENT_ERROR、SERVER_ERROR）和存储类指令（set/add/replace等）的报文格式及处理流程。详细讲解了获取命令（get/gets）的响应格式，以及delete、incr等9种其他指令的功能特点。针对Java开发，比较了三种主流客户端的特点，推荐使用Xmemcached，并给出了缓冲设置、TCP优化等调优建议。最后通过架构图回顾了Memcached的核心知识点，包括网络模型、哈希表、LRU机制

本文介绍了Memcached的内存管理slab机制。slab机制通过slabclass数组管理内存，避免内存碎片，保证高性能读写。每个slabclass按固定大小(chunksize)分配1MB的slab并细分为多个chunk，用于存储Item结构体及key/value数据。Item分配优先从freelist获取，不足时尝试分配新slab或通过LRU淘汰回收空间。数据写入需经过哈希表定位和LRU管理，Item生命周期通过异步/同步方式维护。该机制实现了高效的内存分配和数据管理，是Memcached高性能运行

摘要：Memcached采用多层次的淘汰策略管理过期数据。主要包括：1）通过flush_all指令实现批量key过期；2）惰性删除机制在访问时检查并删除过期key；3）内存不足时同步淘汰冷数据；4）专门的LRU维护线程异步清理。数据按过期时间分为TEMP/HOT/WARM/COLD四类LRU队列，采用差异化的管理策略：TEMP队列快速清理短期数据，HOT/WARM队列有内存限制和状态迁移机制，COLD队列存储长期冷数据。这种分层管理在保证性能的同时实现了高效的内存回收。（150字）

本文深入讲解Memcached的哈希表机制，重点介绍了key定位的实现原理。Memcached通过哈希表（默认6.4万桶，可扩容至43亿桶）实现O(1)时间复杂度的key查找，使用Murmur3或Jenkins哈希算法解决冲突。当元素数量超过桶数1.5倍时会触发2倍扩容，由专门线程暂停其他工作后迁移数据。Memcached还设计了Item锁哈希表（最多32k个锁）确保并发安全，采用桶链表迁移策略保证扩容期间数据访问的正确性。这些机制共同支撑了Memcached的高性能数据存取能力。

本文深入解析了Memcached的网络模型与状态机机制。系统采用基于Libevent的多线程架构，主线程负责连接监听与调度，工作线程处理具体IO操作。状态机通过switch-case实现，包含8个核心状态：从conn_new_cmd初始化连接，到conn_read/conn_parse_cmd处理命令解析，再到conn_nread/conn_write处理数据读写，最终通过conn_mwrite返回响应。特别强调了内存管理策略和错误处理机制，任何异常都会转入conn_closing状态终止连接。文章通过完整

本文介绍了Memcached的系统架构，主要包括五个核心模块：1）基于Libevent的网络处理模块；2）多线程并发模型，采用主线程+工作线程+辅助线程结构，利用epoll实现高效I/O；3）哈希表实现快速key定位，采用渐进式扩容策略；4）分段LRU淘汰机制，将数据分为TEMP/HOT/WARM/COLD四级队列管理；5）slab内存分配机制，通过预分固定大小chunk避免内存碎片。这些设计使Memcached具备高并发、低延迟和高吞吐量的特性，特别适合缓存场景。系统通过多线程充分利用多核性能，LRU和s

本文介绍了Memcached的原理及特性。Memcached是一个高性能的分布式key/value内存缓存系统，采用slab机制管理内存分配，将内存划分为不同大小的chunk存储数据。其特点包括：1)通过哈希表和LRU算法管理数据；2)单节点可达百万级QPS；3)协议简单，仅支持有限命令；4)纯内存操作，自动剔除不活跃数据；5)节点间无通信，由客户端负责数据分布。Memcached作为互联网系统的标配缓存组件，能显著提升系统性能。

本文探讨了缓存系统中的两大经典问题：Hotkey和Bigkey。Hotkey指突发事件引发大量并发访问特定热点数据，导致缓存节点过载；Bigkey则是大体积数据在缓存中引发读写性能问题。针对Hotkey，可通过key分散、多副本架构、本地缓存等方案解决；对于Bigkey，可采用数据压缩、分拆存储、特殊缓存策略等方法优化。文章强调在互联网高并发场景下，需提前识别潜在问题，建立监控机制，并采取分层防御措施，以确保系统在面对流量洪峰和硬件故障时保持高性能和高可用性。

摘要：本文探讨了缓存系统中的两大经典问题：数据不一致和并发竞争。数据不一致问题主要源于缓存更新失败、节点漂移或副本更新异常，可通过重试机制、缩短缓存时间或分层策略解决。并发竞争问题则由高并发场景下缓存未命中引发，解决方案包括全局锁机制和多备份策略。文章结合业务场景（如车票系统和微博）分析了问题成因，并提供了具体的技术应对方案。

本文分析了缓存系统中的三大经典问题及其解决方案。缓存失效问题是由于大批key同时过期导致DB压力骤增，可通过"基础时间+随机时间"的过期策略解决；缓存穿透由查询不存在key引发，可采用空值缓存或布隆过滤器来拦截；缓存雪崩则因节点故障扩散引发系统崩溃，可通过读写开关、多副本部署和实时监控来预防。文章还详细介绍了布隆过滤器的原理与优势，以及微博等大型系统应对缓存雪崩的实际经验。这些解决方案能有效提升系统稳定性，避免因缓存问题导致服务不可用。

本文介绍了缓存系统的架构设计与关键考量点。主要内容包括：1)缓存组件的选择策略，根据业务需求选择Local-Cache或Redis等开源组件；2)数据结构设计要点，针对不同业务场景选择合适的数据格式；3)分布式方案设计，包括取模与一致性Hash的对比选择；4)读写路由方式比较，分析Client直连与Proxy代理的优缺点；5)缓存扩容迁移策略；6)多IDC部署方案；7)8个关键设计考量维度：读写方式、KV大小、Key数量、读写峰值、命中率、过期策略、穿透加载时间和运维安全性。文章为缓存系统设计提供了全面的技

本文介绍了缓存的三种读写模式和两种分类方式。读写模式包括：1）CacheAside（业务方直接操作DB和缓存）；2）Read/WriteThrough（存储服务统一管理读写）；3）WriteBehindCaching（异步批量更新DB）。缓存按宿主层次可分为本地/进程间/远程缓存，按存储介质分为内存型和持久化型。不同模式各有优劣，需根据业务场景在性能与一致性间权衡。典型的缓存组件包括Memcached、Redis、Pika等，适用于不同场景。系统设计需要根据具体需求进行取舍。

本文介绍了缓存的基本原理与应用。首先从狭义和广义两个角度定义了缓存，指出其核心作用是通过高速存储介质加速数据访问。文章详细阐述了缓存的三大基本思想：时间局限性原理、以空间换时间策略及性能成本权衡。分析了缓存的四大优势：提升性能、缓解网络拥堵、减轻服务负载和增强扩展性。同时指出引入缓存带来的系统复杂度增加、成本上升和数据一致性问题等代价。最后通过对比数据库和缓存的性能参数，强调合理设计缓存架构的重要性，既要发挥其高速访问优势，又要规避数据不一致等潜在问题。

摘要：资深技术专家陈波分享缓存技术的重要性及学习方法。作为新浪微博架构师，他亲历系统从零到亿级用户的发展，强调缓存在提升性能、保障高可用性方面的关键作用。课程将系统讲解缓存基础、核心组件（Memcached/Redis）、架构设计及实战应用，帮助开发者掌握构建高性能分布式缓存体系的技能，应对海量数据和高并发场景。通过300分钟精讲，学员可快速掌握缓存设计原理、问题解决方案及行业最佳实践。