Redis深入浅出

17,876 views

Published on

NoSQLFan作者阮若夷在CSDN的BigData大会发言稿:《Redis深入浅出》系统讲解了Redis内部数据结构及实现原理,并列举了使用Redis进行存储的一些典型使用方法。

Published in: Technology
0 Comments
39 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
17,876
On SlideShare
0
From Embeds
0
Number of Embeds
7,051
Actions
Shares
0
Downloads
379
Comments
0
Likes
39
Embeds 0
No embeds

No notes for slide

Redis深入浅出

  1. 1. redis 深入浅出
  2. 2. Agenda <ul><li>Feature&Architecture </li></ul><ul><li>Admin&capcity forecast </li></ul><ul><li>Replication </li></ul><ul><li>Presistence </li></ul><ul><li>Table design </li></ul>
  3. 3. Feature redis memcached data structure string|list|hash|set|zset string thread model third(main thread, two auxiliary thread) many demultiplexer ae.c libevent( 3 rd library ) persistence yes no replication yes no design weak no
  4. 4. String <ul><li>Set hello world </li></ul><ul><li>Set hello 1234567 </li></ul><ul><li>Set hello 1234 </li></ul>
  5. 5. List <ul><li>Lpush list aaaa bbb ccc </li></ul><ul><li>Double link list, so can lpush,rpush,lpop,rpop </li></ul>
  6. 6. Zipmap <ul><li>Hset test hello world </li></ul><ul><li>Hset test aliyun dba </li></ul><ul><li>Zipmap defect:Zmlen one bytes, only 253 subkey </li></ul>
  7. 7. Architecture
  8. 8. Rehash
  9. 9. Cache forecast <ul><li>string 类型的内存大小 = 键值个数 * (dictEntry 大小 + redisObject 大小 + 包含 key 的 sds 大小 + 包含 value 的 sds 大小 ) + bucket 个数 * 4 </li></ul><ul><li>zipmap 类型的内存大小 = hashkey 个数 * (dictEntry 大小 + redisObject 大小 + 包含 key 的 sds 大小 + subkey 的总大小 ) + bucket 个数 * 4 </li></ul><ul><li>Jemalloc size class </li></ul>
  10. 10. Admin <ul><li>Redis.conf(static), config set(dynamic) </li></ul><ul><ul><li>maxmemory <bytes> </li></ul></ul><ul><ul><li>Appendfsync everysec(fsync pagecache to disk) </li></ul></ul><ul><ul><li>hash-max-zipmap-entries 512 </li></ul></ul><ul><ul><li>hash-max-zipmap-value 64 </li></ul></ul>
  11. 11. Replication <ul><li>procedure </li></ul><ul><ul><li>map </li></ul></ul><ul><ul><li>Master slave – slave – slave - slave </li></ul></ul><ul><li>defects </li></ul><ul><ul><li>Without resume broken transfer </li></ul></ul><ul><ul><li>Without lag(slave position) </li></ul></ul>
  12. 12. replication
  13. 13. Persistence <ul><li>Snapshot </li></ul><ul><ul><li>Fork process, loop hash table, save file dump.rdb </li></ul></ul><ul><ul><li>Yes!!! sequential write </li></ul></ul><ul><ul><li>Write dump.rdb need O_DIRECT </li></ul></ul><ul><li>Aof </li></ul><ul><ul><li>Like binlog, for recover after crash </li></ul></ul><ul><ul><li>Auto bgrewrteaof </li></ul></ul><ul><ul><li>Auxiliary threads </li></ul></ul><ul><ul><li>Postpone fsync </li></ul></ul>
  14. 14. Auxiliary thread
  15. 15. Table desgin login user <ul><li>Design a login user system </li></ul><ul><ul><li>Heap table </li></ul></ul><ul><ul><ul><li>userid login_times last_login_time </li></ul></ul></ul><ul><ul><ul><li>1 5 2011-1-1 </li></ul></ul></ul><ul><ul><ul><li>2 1 2011-1-2 </li></ul></ul></ul><ul><ul><ul><li>3 2 2011-1-3 </li></ul></ul></ul><ul><ul><li>Last login man? Create index on last_login_time </li></ul></ul><ul><ul><li>Max login man? Create index on login_times </li></ul></ul><ul><ul><li>Index, explan plan, compute statistics is suck!!! </li></ul></ul>
  16. 16. Login user <ul><li>data </li></ul><ul><ul><li>Set userid:1:login_times 5 </li></ul></ul><ul><ul><li>Set userid:2:login_times 1 </li></ul></ul><ul><ul><li>Set userid:3:login_times 2 </li></ul></ul><ul><ul><li>Set userid:1:last_login 2011-1-1 </li></ul></ul><ul><ul><li>Set userid:2:last_login 2011-1-2 </li></ul></ul><ul><ul><li>Set userid:3:last_login 2011-1-3 </li></ul></ul><ul><li>Last login </li></ul><ul><ul><li>lpush user_last_login 1 </li></ul></ul><ul><ul><li>lpush user_last_login 2 </li></ul></ul><ul><ul><li>lpush user_last_login 3 </li></ul></ul><ul><ul><li>ltrim user_last_login 0 1 </li></ul></ul>
  17. 17. Login user <ul><li>Max login man </li></ul><ul><ul><li>zadd user:login_times 5 1 </li></ul></ul><ul><ul><li>zadd user:login_times 1 2 </li></ul></ul><ul><ul><li>zadd user:login_times 2 3 </li></ul></ul><ul><ul><li>zcard user:login_times </li></ul></ul><ul><ul><li>zrangebyscore user:login_times 3 +inf withscores </li></ul></ul><ul><li>Column store data? </li></ul>
  18. 18. Suitable Scene <ul><li>轻量级的高性能消息队列服务 , 生产者消费者 </li></ul><ul><li>跨机器的共享内存 </li></ul><ul><li>Redis 的主要缺点是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,并且它没有原生的可扩展机制,不具有 scale (可扩展)能力,要依赖客户端来实现分布式读写,因此 Redis 适合的场景主要局限在较小数据量的高性能操作和运算上。 </li></ul>
  19. 19. QA <ul><li>@hoterran </li></ul><ul><li>www.hoterran.info </li></ul>

×