Redis入门二：redhat 6.5安装使用

Redis服务器

Redis目录下都会有一个redis.conf配置文件，里面就是Redis的默认配置，通常来讲我们会在一台机器上启动多个Redis，并且将配置集中管理在指定目录下，而且配置不是完全手写的，而是将redis.conf作为模板进行修改。
使用配置文件启动：redis-server redis.conf的路径/redis.conf

Redis命令行客户端

C/C++操作Redis 使用hiredis
https://www.cnblogs.com/chenshungen/p/4625588.html
https://blog.csdn.net/onlyellow/article/details/80633124

  1 #include 
  2 #include 
  3 #include 
  4 #include "time.h"
  5 int main(int argc, char**argv)
  6 {
  7         struct timeval timeout = {2, 0}; //2s超时时间
  8         //redisContext是Redis操作对象
  9         redisContext *pRedisContext = (redisContext*)redisConnectWithTimeout("127.0.0.1",6379,timeout);
 10         if((NULL == pRedisContext)||(pRedisContext->err))
 11         {
 12                 if(pRedisContext)
 13                 {
 14                         std::cout << "connect error:" << pRedisContext->errstr << std::endl;
 15                 }else{
 16                         std::cout << "connect error: can't allocate redis context" << std::endl;
 17                 }
 18                 return -1;
 19         }
 20         //redisReply是Redis命令回复对象 redis返回的信息保存在redisReply对象
 21         redisReply *pRedisReply = (redisReply*)redisCommand(pRedisContext, "INFO");
 22         std::cout << pRedisReply->str << std::endl;
 23         //每一次执行完Redis命令后需要清空redisReply以免对下一次的Redis操作造成影响
 24         freeReplyObject(pRedisReply);
 25         return 0;
 26 }

Redis这样设计有两个好处：第一，可以改进内部编码，而对外的数据结构和命令没有影响，这样一旦开发出更优秀的内部编码，无需改动外部数据结构和命令，例如Redis3.2提供了quicklist，结合了ziplist和linkedlist两者的优势，为列表类型提供了一种更为优秀的内部编码实现，而对外部用户来说基本感知不到。第二，多种内部编码实现可以在不同场景下发挥各自的优势，例如ziplist比较节省内存，但是在列表元素比较多的情况下，性能会有所下降，这时候Redis会根据配置选项将列表类型的内部实现转换为linkedlist。

字符串类型的内部编码有3种：int(8个字节的长整型)、embstr(小于等于39个字节的字符串)、raw(大于39个字节的字符串)。

列表类型的内部编码有2种：
ziplist（压缩列表）当列表的元素个数小于list-max-ziplist-entries配置（默认512个）、同时列表中每个元素的值都小于list-max-ziplist-value配置（默认64字节）时，Redis会使用ziplist作为哈希的内部实现来减小内存的使用。
linkedlist（链表）当列表类型无法满足ziplist的条件时，Redis会使用linkedlist作为列表的内部实现。
Redis 3.2版提供了quicklist内部编码，简单地说它是以一个ziplist为节点的linkedlist，它结合了ziplist和linkedlist两者的优势。

哈希类型的内部编码有2种：
ziplist（压缩列表）当哈希类型元素个数小于hash-max-ziplist-entries配置（默认512个）、同时所有值都小于hash-max-ziplist-value配置（默认64字节）时，Redis会使用ziplist作为哈希的内部实现，ziplist使用更加紧凑的结构实现多个元素的连续存储，所以在节省内存方面比hashtable更加优秀。
hashtable（哈希表）当哈希类型无法满足ziplist的条件时，Redis会使用hashtable作为哈希的内部实现，因此此时ziplist的读写效率会下降，而hashtable的读写时间复杂度为O(1)。

集合类型的内部编码有两种：
intset（整数集合）当集合中的元素都是整数且元素个数小于set-max-intset-entries配置（默认512个）时，Redis会选用intset来作为集合的内部实现，从而减少内存的使用。
hashtable（哈希表）当集合类型无法满足intset的条件时，Redis会使用hashtable作为集合的内部实现。

有序集合类型的内部编码有两种：
ziplist（压缩列表）当有序集合的元素个数小于zset-max-ziplist-entries配置（默认128个），同时每个元素的值都小于zset-max-ziplist-value配置（默认64字节）时，Redis会用ziplist来作为有序集合的内部实现，ziplist可以有效减少内存的使用。
skiplist（跳跃表）当ziplist条件不满足时，有序集合会使用skiplist作为内部实现，因此此时ziplist的读写效率会下降。

列表的使用场景：

lpush+brpop命令组合即可实现阻塞队列，生产者客户端使用lpush从列表左侧插入元素，多个消费者客户端使用brpop命令阻塞式的抢列表尾部的元素。

数据结构	是否允许重复元素	是否有序	有序实现方式	存储	应用场景
列表	是	是	索引下表	值	时间轴、消息队列等
哈希	否	否	无	键值
集合	否	否	无	值	标签、社交等
有序集合	否	是	分数	键值	排行榜系统、社交等

Redis是单线程来处理命令，一条命令从客户端达到服务端不会立即被执行，所有命令都会进入一个队列中，然后逐个被执行。多个客户端命令的执行顺序是不确定的，但是不会有两条命令被同时执行。Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。

客户端与服务器之间的通信协议是在TCP协议之上构建的。Redis制定了RESP(Redis Serialization Protocol，Redis序列化协议)实现客户端与服务器的正常交互。

http://zeromq.org/

Redis 3.0中文注释
https://github.com/huangz1990/redis-3.0-annotated