尽量原生吧，虽然 T2 是一部还不错的机器

http://item.jd.com/11598400.html#product-detail
http://item.jd.com/11600997.html

https://docs.docker.com/ 这个参考就好，不需要通读

首先声明跟 `链家` 无任何利益关系。

其实 `链家` 在解决这个问题上做的已经很不错了，在房源和房屋质量上做的都不错，房子装修干净（虽说质量一般般），房源基本上没有发生住到一半房东过来赶人的事情。可是大家考虑到价格因素都选择了租房时比较便宜的黑中介，殊不知，退房时被坑掉的钱基本上 **等于** 租 `链家` 时付的服务费。

不是说选 `链家` 不会被坑，至少来说会跟其他黑中介来比，被坑几率会小很多。

目前的情况看来，完全杜绝可能性不大，只能尽量减少，`链家` 在做的就是了，只是他不是公益性的。

在同一家公司还是跨公司？

@mathgl
我也看过，貌似他用 redis 做数据中转用吧，独立于游戏系统，不知道咱俩看到的是不是同一篇……

首先，我还是建议 lz 不要用这种方式使用 redis ， redis 不应该这么用吧，很蛋疼。

当然，如果非要这么用的话， B 的 key 中包含 A 的 ID 应该是一种办法，结构如下：

A 的结构： a_id: {col1: val2, col2: val2}
B 的结构： a_id_b_id: {col1: val2, col2: val2}
但是这样有一个问题就是：如果只有 B 的 ID 想查询 B 就蛋疼了，就得用遍历了……想想就蛋疼


redis 的最佳实践是存一些热数据，尽量不存业务数据，虽说 redis 有持久化方式，如果选择实时持久化那性能还不如 mysql 呢，如果定期持久化那么必然会存在丢数据的问题。我一般用 redis 存一下经常更新的热数据或一些运算结果，我的使用原则是： redis 中的数据可以由业务数据冷启动的，也就是说：如果哪天 redis 挂掉了，只要有业务数据，随时都可以生成 redis 中的数据冷启动的。

用了下兼职好用到爆，不禁给个赞

感觉这个很有用

企业文化是靠人培养的，不是背出来的，这样的公司应该有着大多数员工不认同的“企业文化”
广播体操嘛，不强制的话还好，我曾经在一家公司就是在下午容易困的时候跳，大家自愿，谁爱跳谁跳

而且我知道的一汽丰田也是，到时间就放音乐，跳不跳没有人强制。

kettle ， http://community.pentaho.com/projects/data-integration/
需要些的东西很少，非常好用，免费

有句话叫：学 xxx 最好的时机是十年前，其次就是现在。

可惜在上海……

升级后 bug 多吗？影响正常使用吗？

@jsonfork
hash 数据结构的时间复杂度是 O(1)，所以 hget hset 的时间复杂度都是 O(1)，所以数据量不会影响性能。

@jsonfork
key value 的思想是唯一的 key 对应唯一的 value ，你这种方式叶能实现功能，但是 like 和 hate 操作都会更新同一个 key 的 value ，个人认为不太好，只是个人认为。

最美应用搬来望京 SOHO 了？

@zlkent 用了新版的 win 版迅雷，感觉就是个浏览器，然后下载成了附带的功能……而且浏览器还关不掉……

技多不压身，都学吧。

第一种： hset ， catid 为 key ，结构为：{‘ 1_like ’: 100, ‘ 1_hate ’: 90, ‘ 2_like ’: 20, ‘ 2_hate ’: 10, ....}，不建议 key 中包含长字符串，所以可以用 0 代表 like ， 1 代表 hate ，于是成为：{‘ 1_0 ’: 100, ‘ 1_1 ’: 90, ‘ 1_0 ’: 20, ‘ 1_1 ’: 10, ....}
第二种：直接用 catid_id_like 的形式，如： 1_1_like: 100 ， 1_1_hate: 90 ，同样 0 代表 like ， 1 代表 hate ，成为： 1_1_0: 100 ， 1_1_1: 90

上面适合不同的 catid 下有相同的 item_id ，如果不同的 catid 下面的 item_id 不存在重复的，那么就简单了，第二种，并且 key 中去掉 catid ，表示为： id_like ，如： 1_like: 100 ， 1_hate: 90 ，同样 0 代表 like ， 1 代表 hate ，成为： 1_0: 100 ， 1_1: 90

只是一种思路，具体细节根据 lz 情况自行调整。