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

![《 Redis 实战》封面图]( )

最近，由我翻译的《 Redis 实战》一书（也即是《 Redis in Action 》一书的中文版）终于要在本月下旬正式出版了。

因为我是译者，所以出版社到时候会给我一些样书。因为样书的数量比较多，我一个人看不过来，所以就打算拿出其中五本来送给 V2EX 的朋友们。（样书和普通书本的内容完全一样，只是出版社会给样书盖一个章，说明该书为样书。）

以下是本次赠书活动的规则：

- 想要赠书的朋友请回复本帖，介绍一下你或者你的公司是如何使用 Redis 的，用它来做些什么应用程序，等等。如果你只是对 Redis 感兴趣，但是还没有真正使用过 Redis ，那么可以回复说说你想要阅读这本《 Redis 实战》的原因。

- 本次活动从今天开始，直到 2015 年 10 月 18 日（周日）早上 0 点截止。

- 18 日早上，我将从本帖的所有回复中选出 5 个回复，并向这 5 个回复的作者每人赠送一本《 Redis 实战》。

- 获奖者需要自己支付寄送书本产生的快递费用。快递服务使用顺丰标快，收费方式为货到付款，广东省内收费 18 元，国内沿海城市和主要城市收费 23 元。

- 因为《 Redis 实战》目前还在工厂印刷中，所以本次活动赠送的样书还未寄送到我手上。出版社预计 18 日就会向我寄送样书，等我拿到样书之后就会第一时间将样书转寄给各位获奖者。预计各位获奖者将在本月下旬收到本次活动赠送的样书。

- 本人保留此次活动的最终解释权。

以上就是本次赠书活动的所有规则，欢迎想要赠书的朋友们踊跃参与本次活动。

本次活动赠送的所有样书均由人民邮电出版社提供，特此感谢！

想要了解关于《 Redis 实战》的更多信息，请访问《 Redis 实战》的读者支持网站： [redisinaction.com]( http://redisinaction.com/)

LS667

2015-10-14 14:00:38 +08:00

我只是个凑热闹的

hongcha

2015-10-14 14:40:37 +08:00

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

magensky

2015-10-14 14:43:23 +08:00

Redis 最近在学，求书一本

hantsy

2015-10-14 14:49:00 +08:00

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

已经在多个项目中使用。

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

sincc

2015-10-14 15:26:50 +08:00

我看到作者是 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 的潜能。

zyx89513

2015-10-14 16:23:01 +08:00

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

rangercyh

2015-10-14 16:42:18 +08:00

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

我以前是做端游的，那个时候后台数据冷热是分离的，冷数据落地到 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%了，第一次内测可能也就在这一两个月了，花了一年的时间，中间折腾、纠结、痛苦、悲伤、忧郁、喜悦、兴奋过，一路走来，感慨万千。我的故事说完了，也许永远也说不完。写了这么多废话，主要是今天下午有点闲，然后看到帖子写着写着就废话多了，主要目的不是为了拿本书，不过如果寄给我也非常高兴，耽误大家时间了。

hellomsg

2015-10-14 19:03:43 +08:00

上市后一定拜读

malingyi

2015-10-14 19:15:28 +08:00

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

wangfeng3769

2015-10-14 19:17:05 +08:00

django 一起使用

wangleineo

2015-10-14 19:22:26 +08:00

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

imyip

2015-10-14 19:25:21 +08:00

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

Cfmlovers

2015-10-15 10:03:07 +08:00

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