1. 项目概述从标题拆解Redis核心操作与C集成看到这个标题[Redis#10] scan | db_0 | redis_cli | RESP | C-redis启动教程我猜很多朋友第一反应是这看起来像是一堆Redis相关概念的堆砌。但作为一个在后台开发和数据中间件领域摸爬滚打多年的老手我一眼就能看出这其实是一个典型的“从命令行工具到编程语言客户端再到底层协议理解”的完整学习路径。标题里的每个关键词都指向了Redis使用中一个非常具体且关键的环节。scan命令是处理海量Key时的救命稻草它解决了KEYS *命令在生产环境可能引发的服务阻塞问题。db_0是Redis默认的数据库编号理解它有助于你管理不同业务或环境的数据隔离。redis_cli是我们与Redis服务器交互的瑞士军刀但很多人只用了它不到10%的功能。RESP是Redis序列化协议是理解Redis客户端与服务端通信、甚至自己手搓一个简单客户端的基石。最后的C-redis启动教程则是将理论付诸实践用C这门高性能语言来连接和操作Redis这对于游戏服务器、高频交易系统等对性能有极致要求的场景至关重要。这篇文章我就带你把这几个看似松散的点串成一条线让你不仅知道每个命令怎么用更理解它们背后的设计思想、适用场景以及如何用C高效地整合它们。无论你是刚接触Redis的新手还是想深化理解的开发者相信都能从中找到你需要的东西。2. 深入理解SCAN命令告别KEYS*的生产环境大坑2.1 为什么SCAN是遍历Key的唯一选择在开发或运维过程中我们经常需要查看Redis里有哪些Key或者找出符合某个模式的所有Key。新手最直接的想法就是使用KEYS *或KEYS user:*。这个命令在测试环境、数据量小的时候确实方便。但一旦上了生产数据量达到百万、千万级别KEYS命令就是一个“炸弹”。KEYS命令的问题是阻塞式的。Redis是单线程处理命令的当执行KEYS *时Redis会遍历整个数据库的所有Key一次性构建并返回一个包含所有Key的数组。在这个过程中Redis无法处理其他任何命令。如果数据库里有上千万个Key这个阻塞时间可能达到秒级甚至更久对于在线服务来说这足以引发超时、雪崩等严重故障。而SCAN命令就是为了解决这个问题而生的。它是一种增量式迭代器。你可以把它想象成一本很厚的书KEYS命令要求你一口气读完并复述所有内容而SCAN命令允许你每次只读一页记下当前读到哪一页游标下次从这一页继续读。这样就把一个可能阻塞很久的大操作拆分成多个非阻塞的小操作对服务的影响微乎其微。2.2 SCAN命令的核心参数与工作机制SCAN命令的基本语法是SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]。我们来拆解每个部分cursor游标这是迭代的状态标识。首次调用时游标设置为0。每次调用SCANRedis会返回一个新的游标值。当返回的游标为0时表示迭代已完成。你必须使用上一次调用返回的游标作为下一次调用的参数否则迭代会乱套。MATCH pattern这是一个可选的模式匹配参数和KEYS命令使用的模式规则一样支持*?[abc]等。但有一个至关重要的细节MATCH过滤是在服务器从数据库中取出一批元素之后才进行的。这意味着即使你使用MATCHSCAN仍然需要遍历底层的数据结构比如哈希表槽位。如果匹配的Key非常少你可能会在多次迭代中得到空的返回结果集但这并不代表迭代结束了直到游标返回0才算结束。COUNT count一个提示性的参数默认值是10。你可以告诉服务器“我希望你每次大概返回count个元素”。注意这只是个“提示hint”服务器可能返回比count多一点或少一点的元素甚至在某些情况下比如遍历的是intset编码的小集合或ziplist编码的小哈希/有序集合可能会无视COUNT值一次性返回所有元素。这个参数主要用于在迭代速度和服务器负载之间做一个权衡。值越大每次迭代返回的数据越多总迭代次数越少但单次调用可能耗时稍长值越小单次调用快但总迭代次数多。TYPE type这是SCAN独有的一个强大功能可以只迭代指定数据类型的Key比如TYPE string只找字符串类型的Key。这在清理特定类型数据或做数据统计时非常有用。但和MATCH一样它也是在遍历后过滤不减少服务器的工作量。这里有一个来自官方文档的经典例子展示了使用稀疏匹配模式时可能遇到的情况 scan 0 MATCH *11* 1) 288 # 返回新游标 2) 1) key:911 # 本次迭代只找到一个匹配的Key scan 288 MATCH *11* 1) 224 2) (empty list or set) # 本次迭代没有匹配项 scan 224 MATCH *11* 1) 80 2) (empty list or set) # 本次迭代又没有匹配项 scan 80 MATCH *11* 1) 176 2) (empty list or set) # 还是没有 scan 176 MATCH *11* COUNT 1000 # 增加COUNT让单次迭代扫描更多槽位 1) 0 # 游标归0迭代结束 2) 1) key:611 # 这次一次性返回了所有剩余的匹配Key 2) key:711 ... (共18个Key)这个例子清晰地说明了1) 即使返回空列表只要游标不为0迭代就要继续2) 通过增大COUNT可以调整迭代的“粒度”在匹配项稀疏时适当调大COUNT可以减少空返回的次数提高效率。2.3 SCAN家族命令HSCAN、SSCAN、ZSCANSCAN是遍历数据库中的所有Key。Redis还为集合Set、哈希Hash和有序集合Sorted Set这三种包含多个元素的数据结构提供了专门的迭代命令原理类似。SSCAN key cursor [MATCH pattern] [COUNT count]用于迭代集合中的成员。 SADD myset 1 2 3 foo foobar feelsgood (integer) 6 SSCAN myset 0 MATCH f* 1) 0 # 游标为0一次就迭代完了 2) 1) foo # 返回所有以f开头的成员 2) feelsgood 3) foobarHSCAN key cursor [MATCH pattern] [COUNT count] [NOVALUES]用于迭代哈希表中的字段-值对。它有一个独有的NOVALUES选项如果指定则只返回字段名不返回值这在只需要字段列表时能节省网络传输。 HSET myhash a 1 b 2 (integer) 2 HSCAN myhash 0 1) 0 2) 1) a # 字段 2) 1 # 值 3) b 4) 2 HSCAN myhash 0 NOVALUES 1) 0 2) 1) a # 只返回字段 2) bZSCAN key cursor [MATCH pattern] [COUNT count]用于迭代有序集合中的成员及其分数。重要提示SCAN命令在迭代过程中如果数据库发生了修改增、删、改可能会产生重复或遗漏的元素。这是因为迭代是基于某个时刻的底层数据结构如哈希表的快照视图进行的但在迭代过程中这个数据结构可能因为扩容rehashing而改变。Redis尽力减少了这种情况但无法完全保证一致性。因此SCAN适用于需要遍历所有元素的场景如数据统计、批量删除但不适用于要求强一致性的场景如需要精确判断某个元素是否存在与所有迭代结果中。3. Redis数据库与多DB管理理解db_0的上下文3.1 Redis的“数据库”概念与SELECT命令很多从MySQL这类关系型数据库转过来的朋友会习惯性地认为Redis的db_0、db_1是和MySQL的database一样级别的隔离单位。实际上Redis的“数据库”更接近于一个命名空间。它是一个轻量级的逻辑隔离所有数据库都运行在同一个Redis服务器进程中共享同一个内存和CPU。默认情况下一个Redis实例有16个数据库编号从0到15。你可以通过配置文件中的databases指令来修改这个数量。我们连接Redis时默认进入的就是db_0。切换数据库使用SELECT命令127.0.0.1:6379 SELECT 1 # 切换到数据库1 OK 127.0.0.1:6379[1] # 提示符会显示当前数据库编号 127.0.0.1:6379[1] SET key_in_db1 hello OK 127.0.0.1:6379[1] SELECT 0 # 切换回数据库0 OK 127.0.0.1:6379 GET key_in_db1 (nil) # 在db_0中访问不到db_1的keyFLUSHDB命令可以清空当前数据库的所有数据而FLUSHALL会清空所有数据库的数据使用时务必小心3.2 多DB的使用场景与最佳实践虽然Redis提供了多DB功能但在现代实践中不推荐广泛使用多个数据库尤其是在生产环境。主要原因如下缺乏隔离性多个DB共享内存和进程。如果某个DB的Key数量暴增或某个大Key导致内存激增会挤占其他DB的资源甚至导致整个Redis实例OOM内存溢出被杀死。没有类似CPU、内存的配额限制。管理复杂度客户端需要记住不同数据所在的DB编号增加了代码的复杂性和出错概率。很多Redis集群模式如Redis Cluster直接不支持多DB只使用db_0。备份与监控一些备份工具和监控指标是针对整个实例的难以按DB进行细粒度管理。那么什么情况下可以考虑使用多DB呢本地开发与测试在单机开发环境中可以用不同的DB来隔离不同项目、不同功能模块或不同测试用例的数据避免相互干扰又不需要启动多个Redis实例。简单的数据分类对于一些非常轻量、且明确需要逻辑隔离的数据比如将缓存数据和持久化Session数据放在不同DB。但这通常不如使用不同的Key前缀如cache:user:1,session:user:1来得清晰和灵活。最佳实践是使用Key前缀进行逻辑隔离。例如用user:1001:profile表示用户资料用order:20231001表示订单。这样清晰明了兼容所有部署模式单机、主从、集群也方便通过SCAN命令配合MATCH模式进行批量操作。3.3 在redis-cli和C客户端中操作指定DB理解了数据库的概念我们来看看如何在工具和代码中指定它。在redis-cli中有两种方式连接时指定redis-cli -n 1直接连接到数据库1。连接后切换使用SELECT命令。在C客户端如hiredis或cpp_redis中通常是在建立连接时或连接后发送SELECT命令。我们会在后面的C实战部分详细展开。4. redis-cli不止是命令行更是强大的诊断工具redis-cli是Redis官方自带的命令行客户端很多人只把它当作一个输入命令的窗口。其实它内置了许多高级功能是诊断、调试和批量操作的利器。4.1 基础连接与常用参数-h hostname 指定服务器地址默认127.0.0.1。-p port 指定端口默认6379。-a password 如果Redis配置了密码用此参数指定注意这可能在历史记录中暴露密码不安全。更安全的方式是不带-a连接然后在CLI内使用AUTH命令。-n db 指定连接的数据库编号如-n 1连接db_1。--raw 强制输出原始格式避免对结果进行类型转换或引号处理在处理二进制数据或特定格式时有用。--pipe 启用管道模式用于批量导入数据性能极高。4.2 交互模式与非交互模式交互模式就是我们最常用的直接输入redis-cli回车进入提示符。$ redis-cli 127.0.0.1:6379 PING PONG 127.0.0.1:6379 SET mykey Hello OK非交互模式命令模式则可以直接将命令作为参数适用于脚本调用。# 单条命令 $ redis-cli SET counter 100 OK $ redis-cli GET counter 100 # 多条命令用引号括起来 $ redis-cli MSET key1 v1 key2 v2 OK # 从文件读取命令执行 $ cat commands.txt SET a 1 INCR a EXPIRE a 5 $ redis-cli commands.txt OK (integer) 2 (integer) 14.3 高级功能监控、扫描与基准测试监控模式 (MONITOR)这是一个调试神器。它会实时打印出服务器接收到的所有命令。$ redis-cli MONITOR OK 1698301234.123456 [0 127.0.0.1:65432] PING 1698301235.234567 [0 127.0.0.1:65432] SET foo bar注意MONITOR命令对性能有较大影响因为它需要服务器将每条命令转发给当前连接。绝对不要在生产环境长期开启。大Key扫描 (--bigkeys)这个功能可以快速找出当前数据库中可能存在的“大Key”指value序列化后长度很大的Key。大Key是Redis性能的常见杀手会导致操作延迟高、网络阻塞等问题。$ redis-cli --bigkeys # Scanning the entire keyspace to find biggest keys as well as # average sizes per key type. You can use -i 0.1 to sleep 0.1 sec # per 100 SCAN commands (not usually needed). [00.00%] Biggest string found so far big_string_key with 1024000 bytes [12.34%] Biggest hash found so far big_hash_key with 100 fields ... ...它会使用SCAN命令遍历所有Key并统计不同类型中最大的Key。-i参数可以设置扫描间隔避免对线上服务造成太大压力。基准测试 (--benchmark)用于测试Redis服务器的性能。$ redis-cli --benchmark -n 100000 -c 50 -P 16-n 100000 总共执行10万次请求。-c 50 模拟50个客户端并发连接。-P 16 使用管道pipeline每次发送16条命令。这能极大提高测试的吞吐量。 运行后会输出每秒请求数QPS、延迟等指标。CSV输出 (--csv) 将结果以CSV格式输出方便导入到电子表格或其他分析工具。$ redis-cli --csv LRANGE mylist 0 -1 value1,value2,value3Lua脚本执行 (-x,EVAL)-x参数可以从标准输入读取最后一个参数这在执行复杂Lua脚本时很方便。$ echo return {KEYS[1], ARGV[1]} | redis-cli -x EVAL $(cat) 1 mykey myarg 1) mykey 2) myarg熟练掌握redis-cli的这些技巧能让你在排查问题、分析性能和日常管理时事半功倍。5. RESP协议Redis客户端与服务器对话的语言要深入理解Redis尤其是想用C这类没有官方高级客户端的语言来操作Redis就必须了解RESPRedis Serialization Protocol。它是Redis客户端与服务端通信的底层协议简单、高效、可读性强。5.1 RESP的数据类型RESP定义了5种基本类型每种类型都以一个特定的字符开头简单字符串Simple Strings 以开头后跟字符串以\r\n结束。例如OK\r\n表示成功响应。错误Errors 以-开头格式类似简单字符串但表示错误信息。例如-ERR unknown command FOO\r\n。整数Integers 以:开头后跟整数以\r\n结束。例如:100\r\n。批量字符串Bulk Strings 以$开头后跟字符串的字节长度然后是\r\n再然后是实际字符串内容最后以\r\n结束。这是传输二进制安全数据的主要方式。例如$5\r\nhello\r\n表示字符串 “hello”。空字符串是$0\r\n\r\nNull值用$-1\r\n表示。数组Arrays 以*开头后跟数组的元素个数然后是每个元素元素本身也是RESP类型以\r\n分隔。例如*2\r\n$5\r\nhello\r\n$5\r\nworld\r\n表示一个包含两个字符串 “hello” 和 “world” 的数组。空数组是*0\r\nNull数组是*-1\r\n。5.2 一次完整的通信示例当我们通过redis-cli发送命令SET mykey hello时客户端实际上会向服务器发送一个RESP数组*3\r\n # 数组包含3个元素 $3\r\n # 第一个元素是长度为3的字符串 SET\r\n # 命令名 $5\r\n # 第二个元素是长度为5的字符串 mykey\r\n # Key名 $5\r\n # 第三个元素是长度为5的字符串 hello\r\n # Value值服务器处理完命令后会返回一个简单字符串OK\r\n。对于GET mykey命令客户端发送*2\r\n$3\r\nGET\r\n$5\r\nmykey\r\n。 服务器返回$5\r\nhello\r\n。对于LRANGE mylist 0 -1假设列表有两个元素服务器返回*2\r\n$6\r\nelement1\r\n$6\r\nelement2\r\n。5.3 为什么RESP如此设计简单协议格式极其简单易于实现和调试。你可以直接用telnet或nc命令手动与Redis服务器对话。$ telnet 127.0.0.1 6379 Trying 127.0.0.1... Connected to localhost. Escape character is ^]. *2\r\n$3\r\nGET\r\n$5\r\nmykey\r\n # 手动输入注意换行符 $5\r\n # 服务器返回 hello高效服务器解析非常快因为可以通过第一个字符立即判断类型通过长度前缀可以快速定位数据边界无需复杂的转义或分隔符查找。二进制安全因为使用长度前缀的批量字符串所以可以传输任何二进制数据如图片、序列化对象等不会因为包含\r\n或空字符而被错误解析。可读在调试时人类也能比较容易地看懂协议内容。理解RESP是编写或深度定制Redis客户端的基础。接下来我们就要在C中基于对RESP的理解来连接和操作Redis。6. C连接Redis实战从hiredis到现代封装库C作为系统级编程语言在与Redis交互时我们通常追求高性能和低延迟。这里我将介绍两种主流方式使用官方的C语言库hiredis以及使用一个更现代的C封装库cpp_redis。6.1 方案一使用hiredis官方C客户端hiredis是Redis官方推荐的C语言客户端轻量、高效、稳定。C项目可以直接使用它。第一步安装hiredis在Linux/macOS上通常可以通过包管理器安装# Ubuntu/Debian sudo apt-get install libhiredis-dev # CentOS/RHEL sudo yum install hiredis-devel # macOS (使用Homebrew) brew install hiredis也可以从GitHub源码编译安装以获得最新版本。第二步一个简单的C示例程序创建一个test_hiredis.cpp文件#include iostream #include hiredis/hiredis.h int main() { // 1. 连接到Redis服务器 redisContext *c redisConnect(127.0.0.1, 6379); if (c NULL || c-err) { if (c) { std::cerr Connection error: c-errstr std::endl; redisFree(c); } else { std::cerr Connection error: cant allocate redis context std::endl; } return 1; } std::cout Connected to Redis successfully! std::endl; // 2. 认证如果设置了密码 // redisReply *reply (redisReply*)redisCommand(c, AUTH yourpassword); // freeReplyObject(reply); // 3. 选择数据库例如选择db_1 redisReply *reply (redisReply*)redisCommand(c, SELECT 1); if (reply-type REDIS_REPLY_ERROR) { std::cerr SELECT error: reply-str std::endl; } freeReplyObject(reply); // 4. 执行SET命令 reply (redisReply*)redisCommand(c, SET %s %s, mykey, Hello from C!); if (reply-type REDIS_REPLY_ERROR) { std::cerr SET error: reply-str std::endl; } else { std::cout SET result: reply-str std::endl; } freeReplyObject(reply); // 5. 执行GET命令 reply (redisReply*)redisCommand(c, GET mykey); if (reply-type REDIS_REPLY_ERROR) { std::cerr GET error: reply-str std::endl; } else if (reply-type REDIS_REPLY_STRING) { std::cout GET result: reply-str std::endl; } else if (reply-type REDIS_REPLY_NIL) { std::cout Key not found. std::endl; } freeReplyObject(reply); // 6. 使用SCAN命令迭代Keys (在db_1中) int cursor 0; do { // 注意SCAN命令返回一个数组第一个元素是新的游标第二个元素是Key列表 reply (redisReply*)redisCommand(c, SCAN %d MATCH my*, cursor); if (reply-type ! REDIS_REPLY_ARRAY || reply-elements ! 2) { std::cerr Invalid SCAN reply. std::endl; break; } // 解析新的游标 redisReply *cursor_reply reply-element[0]; cursor atoi(cursor_reply-str); // 注意这里简单处理实际应用应做错误检查 // 解析Key列表 redisReply *keys_reply reply-element[1]; std::cout Iteration cursor: cursor , found keys_reply-elements keys. std::endl; for (size_t i 0; i keys_reply-elements; i) { std::cout - keys_reply-element[i]-str std::endl; } freeReplyObject(reply); } while (cursor ! 0); // 游标为0表示迭代结束 // 7. 清理连接 redisFree(c); return 0; }第三步编译与运行使用g编译需要链接hiredis库g -stdc11 test_hiredis.cpp -o test_hiredis -lhiredis ./test_hiredis如果一切正常你会看到连接成功、设置和获取Key的输出以及SCAN迭代的结果。hiredis的优缺点优点官方维护极致轻量性能最高依赖少。缺点C语言接口需要手动管理内存freeReplyObjectAPI相对底层错误处理繁琐缺乏连接池、重试等高级功能需要自己封装。6.2 方案二使用cpp_redis现代C客户端如果你更喜欢RAII、异常安全、更符合C习惯的API那么cpp_redis是一个很好的选择。它是一个基于C11的异步客户端内部使用hiredis进行通信。第一步安装cpp_rediscpp_redis需要先安装其依赖tacopie一个C11网络库和hiredis。# 1. 安装hiredis (同上) # 2. 克隆并编译tacopie和cpp_redis git clone https://github.com/cylix/tacopie.git cd tacopie mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make sudo make install git clone https://github.com/cylix/cpp_redis.git cd cpp_redis mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make sudo make install第二步一个简单的C示例程序创建test_cpp_redis.cpp#include cpp_redis/cpp_redis #include iostream #include thread #include chrono int main() { // 1. 创建客户端 cpp_redis::client client; // 2. 设置连接参数并连接 client.connect(127.0.0.1, 6379, [](const std::string host, std::size_t port, cpp_redis::connect_state status) { if (status cpp_redis::connect_state::ok) { std::cout Connected to host : port std::endl; } else { std::cerr Failed to connect to host : port std::endl; } }); // 等待连接建立简单处理生产环境应用更健壮的同步机制 std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 3. 选择数据库 client.select(1); // 选择db_1 // 4. 同步执行SET命令cpp_redis也支持异步future client.set(mykey, Hello from cpp_redis!, [](cpp_redis::reply reply) { if (reply.is_string() reply.as_string() OK) { std::cout SET succeeded. std::endl; } else { std::cerr SET failed or got unexpected reply. std::endl; } }); // 5. 同步执行GET命令 client.get(mykey, [](cpp_redis::reply reply) { if (reply.is_string()) { std::cout GET result: reply.as_string() std::endl; } else if (reply.is_null()) { std::cout Key not found. std::endl; } else { std::cerr GET failed. std::endl; } }); // 6. 使用SCAN命令cpp_redis的scan接口 int cursor 0; std::vectorstd::string all_keys; do { client.scan(cursor, my*, 10, [cursor, all_keys](cpp_redis::reply reply) { if (reply.is_array() reply.as_array().size() 2) { // 第一个元素是新的游标字符串形式 auto new_cursor_str reply.as_array()[0]; cursor std::stoi(new_cursor_str.as_string()); // 第二个元素是匹配的Key数组 auto keys_array reply.as_array()[1].as_array(); std::cout Iteration cursor: cursor , found keys_array.size() keys. std::endl; for (const auto key_reply : keys_array) { std::string key key_reply.as_string(); std::cout - key std::endl; all_keys.push_back(key); } } }); // 同步提交并等待本次SCAN完成 client.sync_commit(); } while (cursor ! 0); std::cout Total keys matched: all_keys.size() std::endl; // 7. 断开连接 client.disconnect(); return 0; }第三步编译与运行编译时需要链接cpp_redis和tacopieg -stdc11 test_cpp_redis.cpp -o test_cpp_redis -lcpp_redis -ltacopie -pthread ./test_cpp_rediscpp_redis的优缺点优点现代C API支持同步/异步操作自动重连连接池发布订阅管道pipeline事务等高级特性代码更简洁安全。缺点依赖较多安装稍复杂抽象层带来轻微性能开销对于绝大多数应用可忽略。6.3 方案选型与工程化建议追求极致性能、嵌入式环境或已有C代码基础选择hiredis自己封装一个简单的C RAII包装类。快速开发、需要高级功能如连接池、自动重连、项目为现代C风格选择cpp_redis或类似的库如redis-plus-plus。工程化注意事项连接管理务必使用连接池。频繁创建和销毁TCP连接开销巨大。cpp_redis的cpp_redis::client内部有连接管理而hiredis需要自己实现。错误处理网络是不稳定的。所有网络操作都必须有超时和重试机制。hiredis的redisContext有err字段cpp_redis的回调函数和future需要检查状态。线程安全hiredis的上下文 (redisContext)不是线程安全的每个线程应该使用独立的连接。cpp_redis的客户端对象在并发调用commit时也需要同步。序列化Redis存储的是二进制安全的字符串。在C中存储复杂对象如结构体时需要先序列化。常用方案有JSON如 nlohmann/json、MessagePack、Protocol Buffers或者简单的内存拷贝仅限POD类型。存取时记得做好错误处理。资源清理使用hiredis时务必对每个redisCommand返回的redisReply*调用freeReplyObject释放内存。使用智能指针或RAII类来管理可以避免内存泄漏。7. 常见问题排查与性能优化实战记录在实际使用中尤其是将Redis集成到C应用中时会遇到各种各样的问题。这里我分享几个踩过的坑和优化经验。7.1 连接失败与超时问题问题现象C客户端连接Redis服务器失败或执行命令时超时。排查思路网络连通性先用ping命令和telnet测试基础网络。ping redis-server-ip telnet redis-server-ip 6379防火墙与安全组检查服务器防火墙iptables,firewalld和云服务商的安全组规则是否放行了6379端口。Redis配置检查Redis配置文件redis.confbind 127.0.0.1这行配置会将Redis绑定到本地回环地址只有本机可以访问。需要改为bind 0.0.0.0监听所有网卡或指定服务器IP。注意改为0.0.0.0后务必设置密码或配置防火墙protected-mode yes保护模式开启时如果未设置密码且未绑定到非回环地址会拒绝外部连接。根据你的安全需求调整。timeout 0客户端空闲连接超时时间秒0表示永不超时。如果设置了一个值客户端长时间空闲后需要重连。客户端配置连接超时hiredis的redisConnectWithTimeout函数可以设置连接超时。cpp_redis在连接时也有超时参数。命令超时确保你的Redis服务器性能足够复杂命令如LRANGE一个大列表或SCAN时COUNT值过大可能导致服务器处理时间过长。在客户端设置合理的读写超时。认证失败如果Redis配置了requirepass客户端必须在连接后发送AUTH命令。在hiredis中可以用redisCommand(c, AUTH %s, password)在cpp_redis中使用client.auth(password)。7.2 SCAN命令使用不当导致的问题问题1SCAN迭代不完整或死循环原因没有正确处理返回的游标。必须使用上一次返回的游标值作为下一次SCAN的参数直到返回的游标为0。错误示例在循环中固定使用SCAN 0 MATCH ...这会导致每次都从头开始扫描。正确做法参考本文6.1或6.2节中的循环逻辑。问题2SCAN过程中数据被修改现象在迭代过程中可能有Key被新增或删除导致某些Key被返回多次或遗漏。应对这是SCAN命令的已知特性与底层哈希表扩容有关。如果你的业务逻辑要求强一致的迭代视图有以下选择在业务低峰期执行。使用RDB或AOF备份文件进行离线分析。如果数据量可控且可以接受短时间阻塞使用KEYS命令仅限维护时段。问题3MATCH模式匹配效率低现象使用SCAN 0 MATCH very_specific_pattern*时很多次迭代都返回空列表但游标不为0。分析如前所述MATCH是在服务器扫描出一批Key后才过滤的。如果匹配的Key很少就会产生大量空迭代。优化适当增加COUNT参数的值比如从默认的10增加到1000让每次迭代扫描更多的槽位从而更快地遇到匹配的Key。但要注意COUNT值太大会增加单次命令的响应时间和内存消耗。这是一个权衡。7.3 C客户端内存与性能优化管道Pipeline如果需要连续执行多个不依赖中间结果的命令如批量设置一批Key一定要使用管道。它将多个命令打包一次性发送服务器一次性返回所有结果极大地减少了网络往返延迟RTT。hiredis:redisAppendCommand(c, SET key1 val1); redisAppendCommand(c, SET key2 val2); redisAppendCommand(c, SET key3 val3); // 一次性获取所有回复 redisReply *reply; redisGetReply(c, (void**)reply); // 处理key1的回复 freeReplyObject(reply); redisGetReply(c, (void**)reply); // 处理key2的回复 freeReplyObject(reply); redisGetReply(c, (void**)reply); // 处理key3的回复 freeReplyObject(reply);cpp_redis:client.set(key1, val1); client.set(key2, val2); client.set(key3, val3); // 同步提交所有命令一起发送 client.sync_commit(); // 或者异步提交通过future或回调处理结果 auto future client.commit(); future.wait();连接池对于多线程服务为每个请求创建新连接是灾难性的。必须使用连接池。cpp_redis的客户端内部有一定管理但对于高并发你可能需要自己管理多个客户端对象。可以考虑使用单例模式维护一个连接池。序列化开销如果存储的是C对象序列化和反序列化可能成为瓶颈。对于简单的POD结构可以考虑直接内存拷贝注意字节序和内存对齐。对于复杂对象评估不同序列化库如Protobuf, FlatBuffers的性能。有时将对象拆分成多个Redis Hash字段存储比序列化成一个大字符串再存储在部分读取时更有优势。避免大Key和热Key大Key指一个Key对应的Value非常大如一个包含百万元素的List/Hash。这会导致操作慢、网络传输慢、内存分配问题。解决方法拆分。例如一个大的Hash可以按字段前缀拆分成多个小的Hash。热Key指某个Key被超高频率访问如秒杀场景的商品库存。这会导致单个Redis实例压力过大。解决方法使用本地缓存如memcached、在客户端做一致性哈希将请求分散到多个Redis节点、或者使用Redis Cluster。合理使用数据结构这是提升Redis性能和节省内存的根本。例如存储大量小对象用Hash比用多个String更省内存。需要范围查询的排序数据用Sorted Set。只需要判断是否存在用Set。最新N个项目的列表用List的LPUSHLTRIM。将Redis与C结合就像是给一辆高性能跑车配上了顶级的发动机调校。理解SCAN这样的核心命令让你能安全地驾驭海量数据明白db_0和RESP协议让你洞悉Redis的内部机理而熟练使用redis-cli和选择合适的C客户端库则是你日常开发和排查问题的得力工具。记住没有银弹所有的优化和选择都要基于实际的业务场景和数据特征。多测试多监控根据实际情况调整你的策略才能让Redis在你的C应用中发挥出最大的威力。
1. 项目概述从标题拆解Redis核心操作与C集成看到这个标题[Redis#10] scan | db_0 | redis_cli | RESP | C-redis启动教程我猜很多朋友第一反应是这看起来像是一堆Redis相关概念的堆砌。但作为一个在后台开发和数据中间件领域摸爬滚打多年的老手我一眼就能看出这其实是一个典型的“从命令行工具到编程语言客户端再到底层协议理解”的完整学习路径。标题里的每个关键词都指向了Redis使用中一个非常具体且关键的环节。scan命令是处理海量Key时的救命稻草它解决了KEYS *命令在生产环境可能引发的服务阻塞问题。db_0是Redis默认的数据库编号理解它有助于你管理不同业务或环境的数据隔离。redis_cli是我们与Redis服务器交互的瑞士军刀但很多人只用了它不到10%的功能。RESP是Redis序列化协议是理解Redis客户端与服务端通信、甚至自己手搓一个简单客户端的基石。最后的C-redis启动教程则是将理论付诸实践用C这门高性能语言来连接和操作Redis这对于游戏服务器、高频交易系统等对性能有极致要求的场景至关重要。这篇文章我就带你把这几个看似松散的点串成一条线让你不仅知道每个命令怎么用更理解它们背后的设计思想、适用场景以及如何用C高效地整合它们。无论你是刚接触Redis的新手还是想深化理解的开发者相信都能从中找到你需要的东西。2. 深入理解SCAN命令告别KEYS*的生产环境大坑2.1 为什么SCAN是遍历Key的唯一选择在开发或运维过程中我们经常需要查看Redis里有哪些Key或者找出符合某个模式的所有Key。新手最直接的想法就是使用KEYS *或KEYS user:*。这个命令在测试环境、数据量小的时候确实方便。但一旦上了生产数据量达到百万、千万级别KEYS命令就是一个“炸弹”。KEYS命令的问题是阻塞式的。Redis是单线程处理命令的当执行KEYS *时Redis会遍历整个数据库的所有Key一次性构建并返回一个包含所有Key的数组。在这个过程中Redis无法处理其他任何命令。如果数据库里有上千万个Key这个阻塞时间可能达到秒级甚至更久对于在线服务来说这足以引发超时、雪崩等严重故障。而SCAN命令就是为了解决这个问题而生的。它是一种增量式迭代器。你可以把它想象成一本很厚的书KEYS命令要求你一口气读完并复述所有内容而SCAN命令允许你每次只读一页记下当前读到哪一页游标下次从这一页继续读。这样就把一个可能阻塞很久的大操作拆分成多个非阻塞的小操作对服务的影响微乎其微。2.2 SCAN命令的核心参数与工作机制SCAN命令的基本语法是SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]。我们来拆解每个部分cursor游标这是迭代的状态标识。首次调用时游标设置为0。每次调用SCANRedis会返回一个新的游标值。当返回的游标为0时表示迭代已完成。你必须使用上一次调用返回的游标作为下一次调用的参数否则迭代会乱套。MATCH pattern这是一个可选的模式匹配参数和KEYS命令使用的模式规则一样支持*?[abc]等。但有一个至关重要的细节MATCH过滤是在服务器从数据库中取出一批元素之后才进行的。这意味着即使你使用MATCHSCAN仍然需要遍历底层的数据结构比如哈希表槽位。如果匹配的Key非常少你可能会在多次迭代中得到空的返回结果集但这并不代表迭代结束了直到游标返回0才算结束。COUNT count一个提示性的参数默认值是10。你可以告诉服务器“我希望你每次大概返回count个元素”。注意这只是个“提示hint”服务器可能返回比count多一点或少一点的元素甚至在某些情况下比如遍历的是intset编码的小集合或ziplist编码的小哈希/有序集合可能会无视COUNT值一次性返回所有元素。这个参数主要用于在迭代速度和服务器负载之间做一个权衡。值越大每次迭代返回的数据越多总迭代次数越少但单次调用可能耗时稍长值越小单次调用快但总迭代次数多。TYPE type这是SCAN独有的一个强大功能可以只迭代指定数据类型的Key比如TYPE string只找字符串类型的Key。这在清理特定类型数据或做数据统计时非常有用。但和MATCH一样它也是在遍历后过滤不减少服务器的工作量。这里有一个来自官方文档的经典例子展示了使用稀疏匹配模式时可能遇到的情况 scan 0 MATCH *11* 1) 288 # 返回新游标 2) 1) key:911 # 本次迭代只找到一个匹配的Key scan 288 MATCH *11* 1) 224 2) (empty list or set) # 本次迭代没有匹配项 scan 224 MATCH *11* 1) 80 2) (empty list or set) # 本次迭代又没有匹配项 scan 80 MATCH *11* 1) 176 2) (empty list or set) # 还是没有 scan 176 MATCH *11* COUNT 1000 # 增加COUNT让单次迭代扫描更多槽位 1) 0 # 游标归0迭代结束 2) 1) key:611 # 这次一次性返回了所有剩余的匹配Key 2) key:711 ... (共18个Key)这个例子清晰地说明了1) 即使返回空列表只要游标不为0迭代就要继续2) 通过增大COUNT可以调整迭代的“粒度”在匹配项稀疏时适当调大COUNT可以减少空返回的次数提高效率。2.3 SCAN家族命令HSCAN、SSCAN、ZSCANSCAN是遍历数据库中的所有Key。Redis还为集合Set、哈希Hash和有序集合Sorted Set这三种包含多个元素的数据结构提供了专门的迭代命令原理类似。SSCAN key cursor [MATCH pattern] [COUNT count]用于迭代集合中的成员。 SADD myset 1 2 3 foo foobar feelsgood (integer) 6 SSCAN myset 0 MATCH f* 1) 0 # 游标为0一次就迭代完了 2) 1) foo # 返回所有以f开头的成员 2) feelsgood 3) foobarHSCAN key cursor [MATCH pattern] [COUNT count] [NOVALUES]用于迭代哈希表中的字段-值对。它有一个独有的NOVALUES选项如果指定则只返回字段名不返回值这在只需要字段列表时能节省网络传输。 HSET myhash a 1 b 2 (integer) 2 HSCAN myhash 0 1) 0 2) 1) a # 字段 2) 1 # 值 3) b 4) 2 HSCAN myhash 0 NOVALUES 1) 0 2) 1) a # 只返回字段 2) bZSCAN key cursor [MATCH pattern] [COUNT count]用于迭代有序集合中的成员及其分数。重要提示SCAN命令在迭代过程中如果数据库发生了修改增、删、改可能会产生重复或遗漏的元素。这是因为迭代是基于某个时刻的底层数据结构如哈希表的快照视图进行的但在迭代过程中这个数据结构可能因为扩容rehashing而改变。Redis尽力减少了这种情况但无法完全保证一致性。因此SCAN适用于需要遍历所有元素的场景如数据统计、批量删除但不适用于要求强一致性的场景如需要精确判断某个元素是否存在与所有迭代结果中。3. Redis数据库与多DB管理理解db_0的上下文3.1 Redis的“数据库”概念与SELECT命令很多从MySQL这类关系型数据库转过来的朋友会习惯性地认为Redis的db_0、db_1是和MySQL的database一样级别的隔离单位。实际上Redis的“数据库”更接近于一个命名空间。它是一个轻量级的逻辑隔离所有数据库都运行在同一个Redis服务器进程中共享同一个内存和CPU。默认情况下一个Redis实例有16个数据库编号从0到15。你可以通过配置文件中的databases指令来修改这个数量。我们连接Redis时默认进入的就是db_0。切换数据库使用SELECT命令127.0.0.1:6379 SELECT 1 # 切换到数据库1 OK 127.0.0.1:6379[1] # 提示符会显示当前数据库编号 127.0.0.1:6379[1] SET key_in_db1 hello OK 127.0.0.1:6379[1] SELECT 0 # 切换回数据库0 OK 127.0.0.1:6379 GET key_in_db1 (nil) # 在db_0中访问不到db_1的keyFLUSHDB命令可以清空当前数据库的所有数据而FLUSHALL会清空所有数据库的数据使用时务必小心3.2 多DB的使用场景与最佳实践虽然Redis提供了多DB功能但在现代实践中不推荐广泛使用多个数据库尤其是在生产环境。主要原因如下缺乏隔离性多个DB共享内存和进程。如果某个DB的Key数量暴增或某个大Key导致内存激增会挤占其他DB的资源甚至导致整个Redis实例OOM内存溢出被杀死。没有类似CPU、内存的配额限制。管理复杂度客户端需要记住不同数据所在的DB编号增加了代码的复杂性和出错概率。很多Redis集群模式如Redis Cluster直接不支持多DB只使用db_0。备份与监控一些备份工具和监控指标是针对整个实例的难以按DB进行细粒度管理。那么什么情况下可以考虑使用多DB呢本地开发与测试在单机开发环境中可以用不同的DB来隔离不同项目、不同功能模块或不同测试用例的数据避免相互干扰又不需要启动多个Redis实例。简单的数据分类对于一些非常轻量、且明确需要逻辑隔离的数据比如将缓存数据和持久化Session数据放在不同DB。但这通常不如使用不同的Key前缀如cache:user:1,session:user:1来得清晰和灵活。最佳实践是使用Key前缀进行逻辑隔离。例如用user:1001:profile表示用户资料用order:20231001表示订单。这样清晰明了兼容所有部署模式单机、主从、集群也方便通过SCAN命令配合MATCH模式进行批量操作。3.3 在redis-cli和C客户端中操作指定DB理解了数据库的概念我们来看看如何在工具和代码中指定它。在redis-cli中有两种方式连接时指定redis-cli -n 1直接连接到数据库1。连接后切换使用SELECT命令。在C客户端如hiredis或cpp_redis中通常是在建立连接时或连接后发送SELECT命令。我们会在后面的C实战部分详细展开。4. redis-cli不止是命令行更是强大的诊断工具redis-cli是Redis官方自带的命令行客户端很多人只把它当作一个输入命令的窗口。其实它内置了许多高级功能是诊断、调试和批量操作的利器。4.1 基础连接与常用参数-h hostname 指定服务器地址默认127.0.0.1。-p port 指定端口默认6379。-a password 如果Redis配置了密码用此参数指定注意这可能在历史记录中暴露密码不安全。更安全的方式是不带-a连接然后在CLI内使用AUTH命令。-n db 指定连接的数据库编号如-n 1连接db_1。--raw 强制输出原始格式避免对结果进行类型转换或引号处理在处理二进制数据或特定格式时有用。--pipe 启用管道模式用于批量导入数据性能极高。4.2 交互模式与非交互模式交互模式就是我们最常用的直接输入redis-cli回车进入提示符。$ redis-cli 127.0.0.1:6379 PING PONG 127.0.0.1:6379 SET mykey Hello OK非交互模式命令模式则可以直接将命令作为参数适用于脚本调用。# 单条命令 $ redis-cli SET counter 100 OK $ redis-cli GET counter 100 # 多条命令用引号括起来 $ redis-cli MSET key1 v1 key2 v2 OK # 从文件读取命令执行 $ cat commands.txt SET a 1 INCR a EXPIRE a 5 $ redis-cli commands.txt OK (integer) 2 (integer) 14.3 高级功能监控、扫描与基准测试监控模式 (MONITOR)这是一个调试神器。它会实时打印出服务器接收到的所有命令。$ redis-cli MONITOR OK 1698301234.123456 [0 127.0.0.1:65432] PING 1698301235.234567 [0 127.0.0.1:65432] SET foo bar注意MONITOR命令对性能有较大影响因为它需要服务器将每条命令转发给当前连接。绝对不要在生产环境长期开启。大Key扫描 (--bigkeys)这个功能可以快速找出当前数据库中可能存在的“大Key”指value序列化后长度很大的Key。大Key是Redis性能的常见杀手会导致操作延迟高、网络阻塞等问题。$ redis-cli --bigkeys # Scanning the entire keyspace to find biggest keys as well as # average sizes per key type. You can use -i 0.1 to sleep 0.1 sec # per 100 SCAN commands (not usually needed). [00.00%] Biggest string found so far big_string_key with 1024000 bytes [12.34%] Biggest hash found so far big_hash_key with 100 fields ... ...它会使用SCAN命令遍历所有Key并统计不同类型中最大的Key。-i参数可以设置扫描间隔避免对线上服务造成太大压力。基准测试 (--benchmark)用于测试Redis服务器的性能。$ redis-cli --benchmark -n 100000 -c 50 -P 16-n 100000 总共执行10万次请求。-c 50 模拟50个客户端并发连接。-P 16 使用管道pipeline每次发送16条命令。这能极大提高测试的吞吐量。 运行后会输出每秒请求数QPS、延迟等指标。CSV输出 (--csv) 将结果以CSV格式输出方便导入到电子表格或其他分析工具。$ redis-cli --csv LRANGE mylist 0 -1 value1,value2,value3Lua脚本执行 (-x,EVAL)-x参数可以从标准输入读取最后一个参数这在执行复杂Lua脚本时很方便。$ echo return {KEYS[1], ARGV[1]} | redis-cli -x EVAL $(cat) 1 mykey myarg 1) mykey 2) myarg熟练掌握redis-cli的这些技巧能让你在排查问题、分析性能和日常管理时事半功倍。5. RESP协议Redis客户端与服务器对话的语言要深入理解Redis尤其是想用C这类没有官方高级客户端的语言来操作Redis就必须了解RESPRedis Serialization Protocol。它是Redis客户端与服务端通信的底层协议简单、高效、可读性强。5.1 RESP的数据类型RESP定义了5种基本类型每种类型都以一个特定的字符开头简单字符串Simple Strings 以开头后跟字符串以\r\n结束。例如OK\r\n表示成功响应。错误Errors 以-开头格式类似简单字符串但表示错误信息。例如-ERR unknown command FOO\r\n。整数Integers 以:开头后跟整数以\r\n结束。例如:100\r\n。批量字符串Bulk Strings 以$开头后跟字符串的字节长度然后是\r\n再然后是实际字符串内容最后以\r\n结束。这是传输二进制安全数据的主要方式。例如$5\r\nhello\r\n表示字符串 “hello”。空字符串是$0\r\n\r\nNull值用$-1\r\n表示。数组Arrays 以*开头后跟数组的元素个数然后是每个元素元素本身也是RESP类型以\r\n分隔。例如*2\r\n$5\r\nhello\r\n$5\r\nworld\r\n表示一个包含两个字符串 “hello” 和 “world” 的数组。空数组是*0\r\nNull数组是*-1\r\n。5.2 一次完整的通信示例当我们通过redis-cli发送命令SET mykey hello时客户端实际上会向服务器发送一个RESP数组*3\r\n # 数组包含3个元素 $3\r\n # 第一个元素是长度为3的字符串 SET\r\n # 命令名 $5\r\n # 第二个元素是长度为5的字符串 mykey\r\n # Key名 $5\r\n # 第三个元素是长度为5的字符串 hello\r\n # Value值服务器处理完命令后会返回一个简单字符串OK\r\n。对于GET mykey命令客户端发送*2\r\n$3\r\nGET\r\n$5\r\nmykey\r\n。 服务器返回$5\r\nhello\r\n。对于LRANGE mylist 0 -1假设列表有两个元素服务器返回*2\r\n$6\r\nelement1\r\n$6\r\nelement2\r\n。5.3 为什么RESP如此设计简单协议格式极其简单易于实现和调试。你可以直接用telnet或nc命令手动与Redis服务器对话。$ telnet 127.0.0.1 6379 Trying 127.0.0.1... Connected to localhost. Escape character is ^]. *2\r\n$3\r\nGET\r\n$5\r\nmykey\r\n # 手动输入注意换行符 $5\r\n # 服务器返回 hello高效服务器解析非常快因为可以通过第一个字符立即判断类型通过长度前缀可以快速定位数据边界无需复杂的转义或分隔符查找。二进制安全因为使用长度前缀的批量字符串所以可以传输任何二进制数据如图片、序列化对象等不会因为包含\r\n或空字符而被错误解析。可读在调试时人类也能比较容易地看懂协议内容。理解RESP是编写或深度定制Redis客户端的基础。接下来我们就要在C中基于对RESP的理解来连接和操作Redis。6. C连接Redis实战从hiredis到现代封装库C作为系统级编程语言在与Redis交互时我们通常追求高性能和低延迟。这里我将介绍两种主流方式使用官方的C语言库hiredis以及使用一个更现代的C封装库cpp_redis。6.1 方案一使用hiredis官方C客户端hiredis是Redis官方推荐的C语言客户端轻量、高效、稳定。C项目可以直接使用它。第一步安装hiredis在Linux/macOS上通常可以通过包管理器安装# Ubuntu/Debian sudo apt-get install libhiredis-dev # CentOS/RHEL sudo yum install hiredis-devel # macOS (使用Homebrew) brew install hiredis也可以从GitHub源码编译安装以获得最新版本。第二步一个简单的C示例程序创建一个test_hiredis.cpp文件#include iostream #include hiredis/hiredis.h int main() { // 1. 连接到Redis服务器 redisContext *c redisConnect(127.0.0.1, 6379); if (c NULL || c-err) { if (c) { std::cerr Connection error: c-errstr std::endl; redisFree(c); } else { std::cerr Connection error: cant allocate redis context std::endl; } return 1; } std::cout Connected to Redis successfully! std::endl; // 2. 认证如果设置了密码 // redisReply *reply (redisReply*)redisCommand(c, AUTH yourpassword); // freeReplyObject(reply); // 3. 选择数据库例如选择db_1 redisReply *reply (redisReply*)redisCommand(c, SELECT 1); if (reply-type REDIS_REPLY_ERROR) { std::cerr SELECT error: reply-str std::endl; } freeReplyObject(reply); // 4. 执行SET命令 reply (redisReply*)redisCommand(c, SET %s %s, mykey, Hello from C!); if (reply-type REDIS_REPLY_ERROR) { std::cerr SET error: reply-str std::endl; } else { std::cout SET result: reply-str std::endl; } freeReplyObject(reply); // 5. 执行GET命令 reply (redisReply*)redisCommand(c, GET mykey); if (reply-type REDIS_REPLY_ERROR) { std::cerr GET error: reply-str std::endl; } else if (reply-type REDIS_REPLY_STRING) { std::cout GET result: reply-str std::endl; } else if (reply-type REDIS_REPLY_NIL) { std::cout Key not found. std::endl; } freeReplyObject(reply); // 6. 使用SCAN命令迭代Keys (在db_1中) int cursor 0; do { // 注意SCAN命令返回一个数组第一个元素是新的游标第二个元素是Key列表 reply (redisReply*)redisCommand(c, SCAN %d MATCH my*, cursor); if (reply-type ! REDIS_REPLY_ARRAY || reply-elements ! 2) { std::cerr Invalid SCAN reply. std::endl; break; } // 解析新的游标 redisReply *cursor_reply reply-element[0]; cursor atoi(cursor_reply-str); // 注意这里简单处理实际应用应做错误检查 // 解析Key列表 redisReply *keys_reply reply-element[1]; std::cout Iteration cursor: cursor , found keys_reply-elements keys. std::endl; for (size_t i 0; i keys_reply-elements; i) { std::cout - keys_reply-element[i]-str std::endl; } freeReplyObject(reply); } while (cursor ! 0); // 游标为0表示迭代结束 // 7. 清理连接 redisFree(c); return 0; }第三步编译与运行使用g编译需要链接hiredis库g -stdc11 test_hiredis.cpp -o test_hiredis -lhiredis ./test_hiredis如果一切正常你会看到连接成功、设置和获取Key的输出以及SCAN迭代的结果。hiredis的优缺点优点官方维护极致轻量性能最高依赖少。缺点C语言接口需要手动管理内存freeReplyObjectAPI相对底层错误处理繁琐缺乏连接池、重试等高级功能需要自己封装。6.2 方案二使用cpp_redis现代C客户端如果你更喜欢RAII、异常安全、更符合C习惯的API那么cpp_redis是一个很好的选择。它是一个基于C11的异步客户端内部使用hiredis进行通信。第一步安装cpp_rediscpp_redis需要先安装其依赖tacopie一个C11网络库和hiredis。# 1. 安装hiredis (同上) # 2. 克隆并编译tacopie和cpp_redis git clone https://github.com/cylix/tacopie.git cd tacopie mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make sudo make install git clone https://github.com/cylix/cpp_redis.git cd cpp_redis mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make sudo make install第二步一个简单的C示例程序创建test_cpp_redis.cpp#include cpp_redis/cpp_redis #include iostream #include thread #include chrono int main() { // 1. 创建客户端 cpp_redis::client client; // 2. 设置连接参数并连接 client.connect(127.0.0.1, 6379, [](const std::string host, std::size_t port, cpp_redis::connect_state status) { if (status cpp_redis::connect_state::ok) { std::cout Connected to host : port std::endl; } else { std::cerr Failed to connect to host : port std::endl; } }); // 等待连接建立简单处理生产环境应用更健壮的同步机制 std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 3. 选择数据库 client.select(1); // 选择db_1 // 4. 同步执行SET命令cpp_redis也支持异步future client.set(mykey, Hello from cpp_redis!, [](cpp_redis::reply reply) { if (reply.is_string() reply.as_string() OK) { std::cout SET succeeded. std::endl; } else { std::cerr SET failed or got unexpected reply. std::endl; } }); // 5. 同步执行GET命令 client.get(mykey, [](cpp_redis::reply reply) { if (reply.is_string()) { std::cout GET result: reply.as_string() std::endl; } else if (reply.is_null()) { std::cout Key not found. std::endl; } else { std::cerr GET failed. std::endl; } }); // 6. 使用SCAN命令cpp_redis的scan接口 int cursor 0; std::vectorstd::string all_keys; do { client.scan(cursor, my*, 10, [cursor, all_keys](cpp_redis::reply reply) { if (reply.is_array() reply.as_array().size() 2) { // 第一个元素是新的游标字符串形式 auto new_cursor_str reply.as_array()[0]; cursor std::stoi(new_cursor_str.as_string()); // 第二个元素是匹配的Key数组 auto keys_array reply.as_array()[1].as_array(); std::cout Iteration cursor: cursor , found keys_array.size() keys. std::endl; for (const auto key_reply : keys_array) { std::string key key_reply.as_string(); std::cout - key std::endl; all_keys.push_back(key); } } }); // 同步提交并等待本次SCAN完成 client.sync_commit(); } while (cursor ! 0); std::cout Total keys matched: all_keys.size() std::endl; // 7. 断开连接 client.disconnect(); return 0; }第三步编译与运行编译时需要链接cpp_redis和tacopieg -stdc11 test_cpp_redis.cpp -o test_cpp_redis -lcpp_redis -ltacopie -pthread ./test_cpp_rediscpp_redis的优缺点优点现代C API支持同步/异步操作自动重连连接池发布订阅管道pipeline事务等高级特性代码更简洁安全。缺点依赖较多安装稍复杂抽象层带来轻微性能开销对于绝大多数应用可忽略。6.3 方案选型与工程化建议追求极致性能、嵌入式环境或已有C代码基础选择hiredis自己封装一个简单的C RAII包装类。快速开发、需要高级功能如连接池、自动重连、项目为现代C风格选择cpp_redis或类似的库如redis-plus-plus。工程化注意事项连接管理务必使用连接池。频繁创建和销毁TCP连接开销巨大。cpp_redis的cpp_redis::client内部有连接管理而hiredis需要自己实现。错误处理网络是不稳定的。所有网络操作都必须有超时和重试机制。hiredis的redisContext有err字段cpp_redis的回调函数和future需要检查状态。线程安全hiredis的上下文 (redisContext)不是线程安全的每个线程应该使用独立的连接。cpp_redis的客户端对象在并发调用commit时也需要同步。序列化Redis存储的是二进制安全的字符串。在C中存储复杂对象如结构体时需要先序列化。常用方案有JSON如 nlohmann/json、MessagePack、Protocol Buffers或者简单的内存拷贝仅限POD类型。存取时记得做好错误处理。资源清理使用hiredis时务必对每个redisCommand返回的redisReply*调用freeReplyObject释放内存。使用智能指针或RAII类来管理可以避免内存泄漏。7. 常见问题排查与性能优化实战记录在实际使用中尤其是将Redis集成到C应用中时会遇到各种各样的问题。这里我分享几个踩过的坑和优化经验。7.1 连接失败与超时问题问题现象C客户端连接Redis服务器失败或执行命令时超时。排查思路网络连通性先用ping命令和telnet测试基础网络。ping redis-server-ip telnet redis-server-ip 6379防火墙与安全组检查服务器防火墙iptables,firewalld和云服务商的安全组规则是否放行了6379端口。Redis配置检查Redis配置文件redis.confbind 127.0.0.1这行配置会将Redis绑定到本地回环地址只有本机可以访问。需要改为bind 0.0.0.0监听所有网卡或指定服务器IP。注意改为0.0.0.0后务必设置密码或配置防火墙protected-mode yes保护模式开启时如果未设置密码且未绑定到非回环地址会拒绝外部连接。根据你的安全需求调整。timeout 0客户端空闲连接超时时间秒0表示永不超时。如果设置了一个值客户端长时间空闲后需要重连。客户端配置连接超时hiredis的redisConnectWithTimeout函数可以设置连接超时。cpp_redis在连接时也有超时参数。命令超时确保你的Redis服务器性能足够复杂命令如LRANGE一个大列表或SCAN时COUNT值过大可能导致服务器处理时间过长。在客户端设置合理的读写超时。认证失败如果Redis配置了requirepass客户端必须在连接后发送AUTH命令。在hiredis中可以用redisCommand(c, AUTH %s, password)在cpp_redis中使用client.auth(password)。7.2 SCAN命令使用不当导致的问题问题1SCAN迭代不完整或死循环原因没有正确处理返回的游标。必须使用上一次返回的游标值作为下一次SCAN的参数直到返回的游标为0。错误示例在循环中固定使用SCAN 0 MATCH ...这会导致每次都从头开始扫描。正确做法参考本文6.1或6.2节中的循环逻辑。问题2SCAN过程中数据被修改现象在迭代过程中可能有Key被新增或删除导致某些Key被返回多次或遗漏。应对这是SCAN命令的已知特性与底层哈希表扩容有关。如果你的业务逻辑要求强一致的迭代视图有以下选择在业务低峰期执行。使用RDB或AOF备份文件进行离线分析。如果数据量可控且可以接受短时间阻塞使用KEYS命令仅限维护时段。问题3MATCH模式匹配效率低现象使用SCAN 0 MATCH very_specific_pattern*时很多次迭代都返回空列表但游标不为0。分析如前所述MATCH是在服务器扫描出一批Key后才过滤的。如果匹配的Key很少就会产生大量空迭代。优化适当增加COUNT参数的值比如从默认的10增加到1000让每次迭代扫描更多的槽位从而更快地遇到匹配的Key。但要注意COUNT值太大会增加单次命令的响应时间和内存消耗。这是一个权衡。7.3 C客户端内存与性能优化管道Pipeline如果需要连续执行多个不依赖中间结果的命令如批量设置一批Key一定要使用管道。它将多个命令打包一次性发送服务器一次性返回所有结果极大地减少了网络往返延迟RTT。hiredis:redisAppendCommand(c, SET key1 val1); redisAppendCommand(c, SET key2 val2); redisAppendCommand(c, SET key3 val3); // 一次性获取所有回复 redisReply *reply; redisGetReply(c, (void**)reply); // 处理key1的回复 freeReplyObject(reply); redisGetReply(c, (void**)reply); // 处理key2的回复 freeReplyObject(reply); redisGetReply(c, (void**)reply); // 处理key3的回复 freeReplyObject(reply);cpp_redis:client.set(key1, val1); client.set(key2, val2); client.set(key3, val3); // 同步提交所有命令一起发送 client.sync_commit(); // 或者异步提交通过future或回调处理结果 auto future client.commit(); future.wait();连接池对于多线程服务为每个请求创建新连接是灾难性的。必须使用连接池。cpp_redis的客户端内部有一定管理但对于高并发你可能需要自己管理多个客户端对象。可以考虑使用单例模式维护一个连接池。序列化开销如果存储的是C对象序列化和反序列化可能成为瓶颈。对于简单的POD结构可以考虑直接内存拷贝注意字节序和内存对齐。对于复杂对象评估不同序列化库如Protobuf, FlatBuffers的性能。有时将对象拆分成多个Redis Hash字段存储比序列化成一个大字符串再存储在部分读取时更有优势。避免大Key和热Key大Key指一个Key对应的Value非常大如一个包含百万元素的List/Hash。这会导致操作慢、网络传输慢、内存分配问题。解决方法拆分。例如一个大的Hash可以按字段前缀拆分成多个小的Hash。热Key指某个Key被超高频率访问如秒杀场景的商品库存。这会导致单个Redis实例压力过大。解决方法使用本地缓存如memcached、在客户端做一致性哈希将请求分散到多个Redis节点、或者使用Redis Cluster。合理使用数据结构这是提升Redis性能和节省内存的根本。例如存储大量小对象用Hash比用多个String更省内存。需要范围查询的排序数据用Sorted Set。只需要判断是否存在用Set。最新N个项目的列表用List的LPUSHLTRIM。将Redis与C结合就像是给一辆高性能跑车配上了顶级的发动机调校。理解SCAN这样的核心命令让你能安全地驾驭海量数据明白db_0和RESP协议让你洞悉Redis的内部机理而熟练使用redis-cli和选择合适的C客户端库则是你日常开发和排查问题的得力工具。记住没有银弹所有的优化和选择都要基于实际的业务场景和数据特征。多测试多监控根据实际情况调整你的策略才能让Redis在你的C应用中发挥出最大的威力。
双梁正问题 【 torch 实战】（Python代码实现）)
