Redis c++ client选型

redis client基础库选择

在有限的开发维护人员情况下，redis客户端库版本稳定对我们来说就显得非常重要了，选择使用人数较多的库在遇到问题时得到回复或获得解决问题的办法相对较多，redis官网提供的redis client列表如下：

从列表中我们选择官方推荐的客户端hiredis作为我们的客户端基础库

redis c++ client选型

当我们确定了hiredis作为我们的客户端基础库时，我们就有了大致的选择方向，我们的基础框架平台采用tars框架，完全采用c++语言特性进行开发，所以在使用redis时，需要尽量满足c++的语言特性，并且针对业务模块，应该尽可能的易于使用。hiredis客户端库基于C语言进行开发，功能齐全，但针对c++来说，虽然也可以勉强使用，但需要付出很大代价来进行足够多的上层封装，这会增加我们的开发工作量。有没有直接针对C++的客户端呢？我们从redis的官方客户端列表中找到了针对C++的客户端列表如下：

从列表中我们选取了基于hiredis的客户端，并将各自的特点逐一进行介绍

• c+redis+client: star 58

1. 简单易用，仅包括两个文件，一个cpp一个hpp，较低复杂度
2. 支持redis服务端为单节点，也支持redis服务端作为集群部署
3. 支持pipeline
4. 使用连接池，线程安全，自动重连
5. 不支持windows

查看源码发现针对绝大部分的数据集操作都有封装接口，代码量相对较小，维护成本相对较低，但需要注意的是，代码量相对较小的也意味着将来扩展接口工作量的增加，由于此版本不支持发布订阅、事务、消息队列等操作，仅针对数据存储类做了封装，所以如果后期业务层需要用到类似发布订阅、事务等功能时，需要我们自己新增接口。

• R3C: star 56

1. 简单易用，2个redis client的程序文件r3c.cpp、r3c.h，一个加密类sha1.cpp，一个实用工具类utils.cpp, 复杂度相对较低
2. 支持redis服务端为单节点，也支持redis服务端作为集群部署
3. 对c++11以及更多新版本不依赖
4. 非线程安全，这意味着没有提供数据保护机制，有可能出现多个线程先后更改数据造成所得到的数据是脏数据，当然非线程安全意味着性能优势觉高
5. 不支持pipeline、不支持连接池、不会自动重连
6. 不支持windows

• Redis3M：star 162

1. 简单高效的hiredis封装
2. 使用连接池，使用哨兵模式使得更强的可用性
3. 支持发布订阅，依赖于boost，主要采用字符串形式进行操作，比如存储数据c->run(command(“SET”)(“foo”)(“bar”)),灵活但应用层软件代码容易绑定死，不容易封装接口

• Score-redis：star 0

1. 支持redis服务端为单节点，也支持redis服务端作为集群部署
2. 支持pipeline、async（异步）
3. Api主要以字符操作为主，比如将所有操作的命令整合到字符串中，最后调用exec（）来执行，这样做的好处是灵活，但作为微服务底层编程接口来说，接口不易封装

• Redis-plus-plus: star 112

1. 基于c++11，支持绝大部分的redis命令操作
2. 支持连接池，支持redis 脚本
3. 线程安全
4. 支持发布订阅、支持pipeline
5. 支持事务、支持集群与哨兵模式
6. 接口友好易用，采用类似STL的接口封装
7. 通用命令行接口

对比分析

Feature	c+redis+client	R3C	Redis3M	Score-redis	Redis-plus-plus
Single node && cluster	√	√	×	√	√
pipeline	√	×	×	√	√
Connection pool	√	×	√	√	√
Thread safty	√	×	×	√	√
Publish/subscribe	×	×	-	-	√
transaction	×	×	×	×	√
star	58	56	162	0	112

最终选择

由于我们后期维护人员有限，所以稳定、功能齐全是我们选择的首要目标，所以综合上述方案对比分析之后，redis-plus-plus在我们考虑的各项因素中占据明显优势，所以我选择redis-plus-plus作为c++ client