redis 梳理笔记(一)

一 redis 数据格式

• 短连接 长连接pconnect
• tcp协议

• 交互数据格式

交互采用特殊的格式 \r\n

1."+"号开头表示单行字符串的回复 

    set aa aa  返回的格式就是 +OK\r\n

2."-"号开头表示错误的信息回复。

   ss ss 返回的格式就是-ERR unknown command 'ss'\r\n

3.":"号开头表示一个整数回复。 如":0\r\n"

    del aa返回的格式就是 存在 :1\r\n 不存在 :0\r\n 

4."$"号开头表示一个批量的回复。

 如GET mykey get aa  *2\r\n$3\r\nget\r\n$2aa\r\n

    返回$2aa\r\n

5."*"号开头表示多个批量回复。

 如GET mykey get aa  *2\r\n$3\r\nget\r\n$2aa\r\n

 

• pipe 模型

*3\r\n起始命令表示有3个参数

$3\r\n表示下一个命令参数长度为3

set\r\n参数命令

$2\r\n表示下一个命令参数长度为2

aa\r\n

$4\r\n表示下一个命令参数长度为4

bbbb\r\n

利用这种格式我们可以将数据库中的直接插入redis中

　　

##商品活动
select CONCAT('*4\r\n$4\r\nhset\r\n$',LENGTH(concat('p_white_',item_id)),'\r\np_white_',item_id,'\r\n$',LENGTH(promotion_id),'\r\n',promotion_id,'\r\n' , '$' , LENGTH(promotion_id) , '\r\n' , promotion_id , '\r') from (
  SELECT i.sku as item_id , i.promotion_id as promotion_id
  from mia_test2.promotion as p,mia_test2.promotion_items as i where p.end_time>=now() and p.status=3 and p.id = i.promotion_id and i.status=0
)as t;

mysql -uxxx -pxxx -hxxx   --default-character-set=utf8 --skip-column-names --raw < aa.sql| redis-cli -h 172.16.104.236 -p 6379 --pipe
#300w数据 半分钟导入

 

二 redis 执行流程

　　　

　　　　processInputBuffer 解析协议->processInlineBuffer  processMultibulkBuffer协议

　　　　addReply 是一个list  他会返回结果不断的追加到链表（缓冲区）中，最后输出一起刷新给客户端

三 redis 主从

 　　　　

• Slave端在配置文件中添加了slave of指令，于是Slave启动时读取配置文件，初始状态为REDIS_REPL_CONNECT。
• Slave端在定时任务serverCron(Redis内部的定时器触发事件)中连接Master，发送sync命令，然后阻塞等待master发送回其内存快照文件(2.8+Redis已经不需要让Slave阻塞，此时client 读取的是历史数据)。
• Master端收到sync命令简单判断是否有正在进行的内存快照子进程，没有则立即开始内存快照，有则等待其结束，当快照完成后会将该文件发送给Slave端。
• Slave端接收Master发来的内存快照文件，保存到本地，待接收完成后，清空内存表，重新读取Master发来的内存快照文件，重建整个内存表数据结构，并最终状态置位为 REDIS_REPL_CONNECTED状态，Slave状态机流转完成。（重建整个内存数据结构的时候，slave是阻塞状态，client连接redis 将产生错误）
• Master端在发送快照文件过程中，接收的任何会改变数据集的命令都会暂时先保存在Slave网络连接的发送缓存队列里（list数据结构），待快照完成后，依次发给Slave,之后收到的命令相同处理，并将状态置位为 REDIS_REPL_ONLINE。
• 在2.8之后replication 支持增量复制，Master会在其内存中创建一个复制流的等待队列（list数据结构），Master和它所有的slave都维护了复制的replication offset 和 a master run id，因此，当网络连 接断开后，Slave会请求Master继续进行未完成的复制，从所记录的replication offset 开始。如果run id变化了，或者replication offset 不可用，那么将会进行一次全部 数据的复制.(当Master变更，Slave端会进行一次全量同步，主备从方案)
• 每增加一台从库，Master端都会重新执行一遍主从复制，建议从库最好一次性增加好，或者不要在服务器繁忙的时候增加从库
• 不建议redis的内存设置超过32G,redis replication 时 bgsave 会消耗大量的内存，传输快照文件时会消耗大量带宽，  load快照会锁死从库.

• bgsave 很消耗内存 请预留redis已使用量 一半的内存用于 bgsave子进程消耗。

    http://redis.io/topics/replication