赠送几本即将出版的《Redis 实战》

支持下！

用 redis 来做数据缓存，存的是一些“不那么重要”、“可小部分丢失”的数据。但由于业务上需要快速地读写这些数据，所以采用了 redis 。
最近刚把版本升级到了 redis-cluster ，从以前在程序里“粗糙”地实现集群，到现在可以简单地交给 redis-cluster 实现，另外 hash slot 的概念也很有用，可以方便地添加节点。
但问题是发现这个新事物还是有些坑的，所以还在研究学习中。

近期在做一个高并发场景的项目，每秒处理数万请求；所以呢，用 Redis 的首要目标是缓存数据库查询结果。

某种数据的数据量和查询量都很大，数亿乃至数十亿条目，每秒数十万次查询；所以搭建了一套 6 节点的集群来处理。原来定的是用 512GB 内存的服务器，后来才知道内存大到一定程序性能未必跟得上来，又换用 64GB 的了，反正未来随时可以增加节点来扩展性能嘛。

不过发现 Java 的 Redis API 还不够健全，同时某些方法在 Redis 集群里也支持的不好。取交并集、计数等都存在一些问题，为了处理其他几种小量数据，于是又建了一套 2 节点、主从结构的 Redis ，这次有必要的话可以用得上 512GB 的了。><

系统中有一处涉及交易金额的计算，需要在集群环境中实现一个延时队列，以保证及时退还超时交易的冻结款。因 Web 服务节点众多，共享队列不好实现，所以这个担子自然就落在了 Redis 身上。通过有序集合，将 key 与时间 Redis ，另在 Web 节点上起线程执行解冻操作。后来发现几乎是某节点独立完成了所有的解冻操作，让人啧啧称奇；直到很久以后发现这台机器的 NTP 没有工作，系统时间快了几秒。

冻结操作需要判断，以避免高并发下账户超额支出；因为一开始对 Redis 不太熟悉，考虑了用锁的方式。不过，乐观锁也不适合这种高并发的场合。后来索性通过程序，维护冻结款和余额等之间的变化关系，虚拟出一个可用金额的变量，它们之间实时的存在等式关系；然后用单一变量「可用金额」扣除价格是否为正数，来判断是否可以交易。整个过程使用 zincrebyfloat ，原子操作，妈妈再也不用担心高并发出错啦！

其实用了 zincrebyfloat 之后呢，金额就变成了 100.049999000000099 这样，不过精度已经足够使用了。

缓存中的数据也经常变化，所以隔上相当一段时间，肯定要清空一次数据。但是担心这么大的数据操作影响实时性能，只好用 zscan 慢慢的遍历数据，悄悄的判断，从后面抹了无用数据的脖子，把它们逐个干掉。

但是在某些情况下，还是需要直接的清空数据。摸索之后发现逐个节点清空就可以做到，因为担心主从结构会导致问题，于是想办法来智能区分每节点是主还是从，后来一想反正在 master 上的修改会自动同步到 slave ，如果 slave 上发生问题就可以直接跳过的嘛，于是工作量上又节(neng)省(tou)了(lan)些(le)。

先路过滋辞一下。
因为比较懒所以很依赖书，而不是自己去读别人成熟的开源项目
更希望了解更多的应用场景 嘛 希望运气好抽到一本~
顺便：作者翻译也不容易！希望能看到你更多的作品~

@sincc redisinaction.com 上面有给出目录，还有试读，方便参考。

恭喜撸主，能把我这种资深级潜水党给炸出来。。
说实话我回复仅仅是为了能拿个小奖，拜读一下 redis 实战这本。。
原本看看英文版那是最好不过了，无奈本人英语是体育老师教的（体育老师一直都是被黑的）。。
所幸大神把这本书给翻译了，希望能够拜读一下此书。
----------------------------------------------我是分割线---------------------------------------------------
我们公司用 Redis 来缓存 session ，解决应用的集群问题
另外还缓存不经常更新的热门数据，比如商品报价单信息
redis 就是一个非关系数据库，可以弥补关系型数据库的一些缺陷， redis 和关系型数据库配合使用，就像双剑合璧的杨过和小龙女，功力（吞吐量）大增
----------------------------------------------我是分割线---------------------------------------------------
我只想要这本书。

这一周内见到两位译者在 V2EX 宣传自己的新作。我们公司是深圳中青宝，主要业务就是游戏开发和运营。使用 Redis 作为存储用户数据及游戏场景数据等，并辅以 Mysql 作为持久化存储工具；您可以访问我的网站： http://mrlong.sinaapp.com 了解更详细的使用场景。

redis 用得不多，一般用作可以定时销毁的 session ，例如数字验证码、手机验证码，超时就自动销毁。

求书求书（

好吧 说一下我们操蛋的用法，由于没有推送 我们需要把设备信息存在 redis 里面进行，每次客户端轮训，然后我们判断设备再给内容。求书……

Redis 最近在学 感觉不错

MARK 下。楼主翻译完了，能不能客观评价下这本书到底怎么样

我想要从浅到深的了结 REDIS 可以为 PHP 做什么。

又有新书 来看看 凑个热闹

看到大家的回复，确实收获颇多。我之前用 redis 作为 session 和限制用户登录。后来一个视频直播项目，用 redis 临时存储用户评论，直播结束后存入 sql 数据库。还有利用 redis 作为数据库的二级缓存，减少 sql 数据库的连接次数！

留名，了解过 redis ，但是公司的项目暂时没用上，不期望得到赠书。正版出来买买买！

作为学生支持一下~
qaq 没用过这种服务器的数据库 QAQ [好像是这样的。。。

只用过 MYSQL 的只能默默看了~~

支持翻译~~

公司准备下一步做 redis 的项目，目前还没有买过书，只是从网上找资料看 所以想入门一下

reply for fun

公司有个项目准备使用 redis 了 但是没有相关经验 所以想看看

伪全栈想要学学

我只是个凑热闹的

一方面目前公司把 redis 当作缓存使用，使用 string 的 key － value 存储
另一方面把 redis 当作队列存储使用，使用 list 一边 push 一边 pop
好想要这本书

Redis 最近在学，求书一本

1. Spring 下有一个 Spring Session 项目，用 Redis 实现 HTTP Session 接口，结合 Spring Security 可以实现 Session 可享，基于 Token 的身份验证，适合于 Web 程序和 RESTful API 。

已经在多个项目中使用。

2. 另外可以存放一此统计类的数据。
3. 临时数据，如果验证码之类，自动过期。

我看到作者是 13 年写的，不知道现在内容是否合适，因为 redis 已经 3.0 了， cluster, sentinel 都日臻成熟。我们公司做物联网的，后端的所有数据库都是 redis 。在我们产品了的主要作用是：

1. 存储用户数据，支持快速读写操作，具体的用户数据关联十分复杂， redis 在关联这块比较欠缺，也可能这是 redis 的设计初衷吧。

2. 作为 memory cache ，手机验证码，找回密码之类的临时数据

3. sentinel 支持服务器的 HA ，如果 master 宕机，会选举一个 slave 重新变成 master

4. 利用 redis 的 dist lock ，分布式锁来支持分布式开发。

5. 作为 backend ，结合 apscheduler 实现类似 cron 的功能。

6. 其他

总之我们对 redis 的需求挺大的，也希望能挖掘 redis 的潜能。

@huangz 能否告诉几个图书编辑的微博账号呢? O(∩_∩)O 谢谢

谢谢楼主，介绍一下我正在开发的游戏吧。

我以前是做端游的，那个时候后台数据冷热是分离的，冷数据落地到 mysql 或者 oracle 之类的关系型数据库里，当服务器启动的时候从数据库里把冷数据做一定筛选加载进内存里，然后当玩家登录时玩家数据也被从数据库加载进内存。玩家数据的存储有两种方式，一种是按照一定时间间隔进行热数据落地，一种是一旦发生变化就落地。那个光辉岁月里，服务器启动的时候要加载很多公共数据，所以对于一个日活上万的服，注册比按 1 ： 100 来算，如果数据处理写的不好，很可能服务器启动的时候要加载很大一片数据进内存，通常服务器启动要花上好几个小时，就好像开炮前要预热炮管一样。那个时候，每当设计到新的数据，都要考虑数据的落地时机和落地频率，还要考虑数据的访问频度和每次访问的数据大小，其实这些都是应该考虑的，不过在那个年代被放大了，其实数据的落地跟真正的游戏逻辑没有多大关系，在理想服务器下，有没有数据库，对游戏都没什么影响，只要服务器不关闭或者宕机就没有问题。

然后我开始做手游了。

第一次做手游，想脱离原来端游的做法，把自己在做端游时的不满和艳羡的技术都用起来，想走出一片广阔的天空。首先是服务端的语言，之前端游的时候服务器用的 c++和 lua 来写的，一个服务端的代码恨不得有好几十兆，当然不止是游戏逻辑的进程，还有别的进程，加在一起。既然做新游戏了，我自然想耍一耍新的东西，纠结了很久我还是放弃了早已熟悉的 c++和 lua 的架构，开始动手重写一个新的服务器，当时首先想到的是看看别人是怎么尝鲜的，于是在 github 上发现了网易的 pomelo ，由此接触了 nodejs ，当然还看过云风大大的 skynet ，但是我想走的更远，最后纠结了 1 个月是改造 pomelo 还是自己动手写，最后被朋友劝说，一步一步往上爬，才能在最高点乘着叶片往下飞，于是我动手从 0 开始写我的服务器了。花了将近一个月，不停的推翻重构，终于把服务器框架搭好了，那段时间睡觉都在思考服务器的架构，现在想想也是醉了，整体的架构非常精简，而且优美，至少当初我是这么认为了，主要的技术用到了 zmq ，其他的就是兼顾扩展性和灵活性，如果有想了解的朋友可以和我沟通。
然后是发现手机平台由于没有 pc 平台那么强大，所以表现力有限，这不光精简了客户端，同时也减轻了服务端的逻辑，很多人直接用 http 这种短连接来做服务端，这在我做端游的时候是很难想象的，尤其是一些 mmo 的游戏，而端游时代几乎放眼望去 mmo 是最多的，手游有很多不需要这么强连接的游戏，所以短连接也是可以理解的。我先封装了 nodejs 的 tcp socket ，测试性能发现，单个 node 进程 2Wqps ，单包 10bytes 几乎毫无压力，先用了段时间，后来由于客户端的需求，我还是选了折中的协议 websocket ，虽然性能有所下降，但还可以接受。
最后终于到数据库了，由于设计服务器进程的时候，我首先的想法就是不能像以前端游那样，由服务器进程来保存游戏状态，我一定要把状态放进数据库来维护，又不想牵扯冷热数据的问题，而且服务器语言用的是 nodejs ，所以我毫不犹豫的瞄向了 redis 这样的内存数据库，当然有人要争辩 redis 的真正作用，我并不是真的了解它，只是觉得它可爱，小巧，好用。我需要一个读写性能极高的数据库，又不想考虑冷热数据交互，还要求简单易用，当时考虑了 mongodb 跟 redis ，甚至还考察过 leveldb ，最后还是 redis 的简单让我选择了它，“古人”不是说过简单即是美吗，哈哈。基于我服务器的设计， redis 承载的不光是保存数据的任务，还需要参与到游戏逻辑中来，跟我在做端游时完全不同，端游时的数据库是和游戏逻辑分离的，只起到存储和恢复数据的作用，而现在 redis 的作用跟游戏逻辑耦合的更加紧密，如果从这个角度来看，似乎服务器更加复杂了，因为引入了另一个模块来操作游戏逻辑，数据和逻辑杂糅在一起了，但精心的设计和 redis 的简洁性让这件事情看起来没有那么复杂， redis 内建的结构也非常好用，我们用到了 set 、 string 、 hash ，使用了 expire 、 pub/sub 订阅、 key space notification 等等特性。现在我们的游戏逻辑和 redis 已经是水乳交融了，我自己也不知道怎么拆开了。囧。。。另一个需要考虑的问题，是数据的安全性，虽然这个问题不属于游戏逻辑的考虑范围，但本着做人要负责的态度，既然上了床，就要考虑生宝宝的问题。我详细思考和测试过 redis 的备份方案，无论 rdb 还是 aof ，无论是主从还是读写分离，都没有令我觉得完美，也许压根就不存在完美的备份方案，迄今我还在搜寻着，思考着。

我的项目完成度已经接近 80%了，第一次内测可能也就在这一两个月了，花了一年的时间，中间折腾、纠结、痛苦、悲伤、忧郁、喜悦、兴奋过，一路走来，感慨万千。我的故事说完了，也许永远也说不完。写了这么多废话，主要是今天下午有点闲，然后看到帖子写着写着就废话多了，主要目的不是为了拿本书，不过如果寄给我也非常高兴，耽误大家时间了。

上市后一定拜读

1, 充当缓存服务
2 ，充当消息中转站，大部分是 Log 消息，通过 pub ／ sub 的方式使用
3 ，折腾过 3.x 的集群，由 Server 端负责 sharding
4 ，充当 Global Session

django 一起使用

我来搬个砖
http://highscalability.com/blog/2011/7/6/11-common-web-use-cases-solved-in-redis.html

说实话,我对 Redis 并不太了解,没有在实际环境上使用过,只是知道他缓存挺好用
现在觉得自己只是太贫乏了,半桶水的 php 作为应届生找不到好的工作
持续关注楼主的新书动态,上市的话告知一下

公司级别的云存储有很多，但是很多项目还是会去选择 redis 作为存储，从一个使用者的角度来看， redis 是方便部署与运维的，读写速度非常快，作为 local 存储是一个不错的选择
我手里的这个项目是一个棋牌类的游戏，采用的是 redis+mysql 的存储方式，网上很人问，怎么样将 mysql 的数据迁移到 redis ，其实是一个误区，对个人的项目使用 redis 的定位一定要清楚，是缓存，还是存储。 redis 的数据结构基本上都有用到，持久化，主从同步，订阅功能， lua 脚本等等，也都在使用。
最近做的一个比较有趣的事情是， redis 集群部署的虚拟机性能不够好，持久化的时候磁盘 IO 不给力，所以需要将 redis 集群迁移出来，因为是线上的服务，所以需要做到无缝迁移，参考官网给的教程，迁移过程中出现了一些官网没有提示的异常情况，比如 del-node 的节点重新启动之后又加入了集群等等，集群这块的去中心化的设计值得参考
自己也一直在阅读 redis 的源码，也做过 redis 源码的剖析分享，随处可见为了内存优化做的设计，包括精巧的数据结构，哪怕是 key 的查询都会做到常量级的复杂度
首先要做好定位，为什么要使用 redis ，在去了解了一些关于 redis 的基本功能和注意点之后在去使用他，总之， redis 是一个不错的开源存储产品。

Redis 最近在看，公司准备做几个互联网项目，需要云存储以及其他分布式缓存之类的，刚好想借楼主的书学习一下，多谢楼主

原书是 13 年出版的,这都 2 年了才翻译.........

看能抽到不

@finian 电子版也会有，但会比纸质版晚。

@Rsl 电子版会出的，不过因为版权的问题，会比纸书晚一些，需要等待一阵子。

活动截止时间已到，感谢大家对本活动的支持。

今天之内将公布获奖者名单，敬请期待！

获奖者名单已经公布，感谢大家对本活动的支持！

@huangz 看到我的 ID 了 ^^

@shellfly 恭喜，感谢你的回复，内容很有趣。

我已经收到你的邮件，并给你回复了，发邮件的是你吗？

@huangz 是的

@shellfly OK 。

@huangz 我收到你的回复了，希望你的书大卖。

@carlosfu 谢谢！

bingo 了！邮件已发，望回复，祝大卖 @huangz

@rangercyh 已回复你的邮件，谢谢！

@lijinma 你好，我收到了你一封邮件，并且已经回复了，是你本人吗？

@huangz 确认是本人，谢谢你。

@lijinma OK 。

@ynztyl10 hi ，在吗？你中奖了，请给我发邮件。

@huangz sorry ，刚看到，邮件已发，谢谢啦

@ynztyl10 没关系，已经给你回邮件了。

@huangz 感谢，邮件已收到

@huangz 十分感谢，书已收到，很赞

@ynztyl10 不客气，收到就好！

已购买，期待早日出电子版

@boboweb 谢谢支持！等电子版出了之后会第一时间发布消息的。

已经购买，快看了一半了，内容比较实用。

@markme 谢谢支持。