都说Redis快，到底快在哪

最近做首页推荐相关业务，需要实现一个兜底方案，以备在调不通数据接口的情况下，也可以有数据推荐给用户，保证正常的浏览和良好的体验。

这个方案强依赖于redis，将热销商品、库存状态、上下架状态等等通过脚本写入redis，然后程序从redis里取出并做一系列过滤、去重、多样化等处理。

于是乎对redis的读取速度有极高的要求，开发测试中发现，按500条普通数据来算，当分每批次50个进行mGet时的10几ms，比一次性全部mGet的2-4ms,慢了好几倍。对redis的处理方式有点模糊

于是，翻看了一些资料，对redis 有了一些初步的了解，简单的记录一下，以便日后翻看。

-----------------------------------------------------------------------------------------------

redis之所以快，是因为，1：纯内存操作 ，2：异步非阻塞 IO。。。

对于现在的机器配置，纯内存数据库，内存不是瓶颈。一般情况下，hash 查找可以达到每秒数百万次的数量级。

瓶颈在于网络IO。绝大多数时间，消耗在了网络传输上，这也就解释了为什么一次性mGet ,要比批次mGet要节省时间了。如果将redis安装在与服务相同的机器上，其读取速度，会大大提高。

锁不会过于影响性能。线程锁 (mutex_lock) 只有在遇到冲突的情况下性能会下降，而正常情况下，遇到冲突的概率很低。如果只是简单的加锁、释放锁速度是非常快的，每秒钟上千万次没问题。 线程也不会影响效率。因为处理内存数据的速度远高于网卡接收的速度。使用线程好处是可以同时处理多条连接，

下班了，以后查全资料再补吧