Redis 架构分析及源码剖析.ppt

Slow log 为什么叫“慢日志”？是什么慢呢？慢多少呢？ ? “慢”特指命令执行的速度，Redis会统计每条指令的执行时间，如果执行时间超一个参考标准，就往日志里插入一条记录。这个参考标准就是server.slowlog_log_slower_than这个配置参数，这个参数的默认值是1000000微秒(即1秒)。 用处: 跟踪性能，分析调优。 实现: 存在于内存的链表结构，每个节点都是slowlogEntry结构，不能持久化。 Lua script 九、修改调试 十、总结展望 KISS原则 无时不刻体现了KISS原则。(事件框架、线程模型、数据结构) 自我改良 哈希重置(Rehash)，AOF重写(AOF Rewrite)、过期键淘汰都体现了这种思想。改良的代价远远小于革命，对现有系统冲击非常有限。在保证现有系统的可用情况下，通过自我迭代式的改良，量变到质变，使得系统进化。 ? 出神入化的指针使用 SDS、 ? 内存优化 压缩(ziplist、zipmap) 回收(过期key、hash收缩) 享元(FlightWeight) ? 先进经验!!! 内存吞噬 数据+指令缓存+慢日志，严重依赖内存，持久化充其量是一个磁盘备份，不适合海量数据！ 单线程 redis虽然宣称主从复制无阻塞，但是，由于redis使用单线程服务，而和slave的交互由处理线程统一处理，因此，对性能有影响。在slave第一次和master做同步时，如果master快照文件较大，则快照文件的传输将耗费较长时间，文件传输过程中master无法提供服务。 一些具体实现效率不高如时间事件的处理，每次都是从时间事件链表里取出一个触发期距离当前时最近的一个，然后做处理，算法复杂度为O(n)。 只支持单向同步 没有原生的扩展机制 不具有scale能力，需要依赖客户端的分布式读写 缺陷!!! 忠告!!! 根据业务场景选择适合数据类型 最好的使用方式in-memory！ 慎用：keys * 、 mMethod、save。 对容量一定要有预估！ 内存吞噬者！ 宕机后恢复时间超乎你的预期(他人经验) Replication的缺陷 小心 bgrewriteaof存在问题。 不要过度依赖持久化与复制 了解实现后使用，scripting 展望 据说Redis cluster将在3.0版本推出。会有集群自动sharding，多节点容错。 Redis 3.0 1)节点之间相互通讯(与服务器不同端口)； 2) 所有的key被分成几千份(hash slot)，分布在所有节点中。 3)新增节点后，会把相应数据转移 4)新的key操作会转移到新的节点，老的key操作每次都会询问老节点是否已经转移 5)转移完成后所有之后的请求之间请求新节点 read Proxy(Consistent Hash) master master master client slave slave slave slave slave slave Twemproxy? Redis官方网站 http://redis.io 命令列表 http://redis.io/commands Redis中文站 /commands.html 命令中文参考 /en/latest serviceStack.redis类结构图 /img/Redis-annotated.png Redis性能测试与说明 http://redis.io/topics/benchmarks 携程旅行网 * * * 托马斯王32位混合 unsigned int dictIntHashFunction(unsigned int key) { key += ~(key 15); key ^= (key 10); key += (key 3); key ^= (key 6); key += ~(key 11); key ^= (key 16); return key; } djb算法 一个大小写无关的散列算法，代码很少： unsigned int dictGenCaseHashFunction(const unsigned char *buf, int len) { unsigned int hash = (unsigned int)dict_hash_function_seed; while (len--) { hash = ((hash 5) + hash) + (tolower(*buf++)); //hash * 33 + c } return hash; } 3个hash算法 Murm