关于redis在电商项目中的理解

在项目中，缓存的应用于：系统中并发量比较高的地方，需要频繁对数据库进行插座的地方，我们会设置redis缓存，一般在商城首页，广告首页，搜索面板数据，购物车等等，

redis缓存的利用率的提高，在于分析数据是否热点，，我们会通过对redis缓存数据设置有效期来控制数据。

热点数据会在到期后自动添加到缓存中，非热点数据到期都不会直接添加到缓存，而是当用户去访问时，才去添加。

redis缓存的同步也是很重要的，避免出现错误数据。就是说，当我们对数据库进行，增，删，改，操作时，要将redis缓存中对应的数据删除，当页面再次访问时，会直接去数据库里查询数据，并将新的数据保存到redis缓存中。

关于redis缓存是使用的nosql非关系型数据库，它的存储格式是key-value的形式，因为它储存位置在内存(缓存)中，读写效率特别快，自然查询速度也是很快的，但成本高。

redis不适合存储大数据，首先，成本高，其次，它是单线程，会造成其他进程堵塞，性能降低。

类似于商品评论这样价值不高的大批量数据，我们会采用moogodb。

moogodb

    优点

    面向文档存储(类JSON数据模式简单而强大)

    动态查询

    全索引支持,扩展到内部对象和内嵌数组

    查询记录分析

    快速,就地更新

    高效存储二进制大对象 (比如照片和视频)

    复制和故障切换支持

    Auto- Sharding自动分片支持云级扩展性

    MapReduce 支持复杂聚合

    商业支持,培训和咨询

    缺点

    不支持事务（进行开发时需要注意，哪些功能需要使用数据库提供的事务支持）

    MongoDB占用空间过大 （不过这个确定对于目前快速下跌的硬盘价格来说，也不算什么缺点了）

    MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方

    在32位系统上，不支持大于2.5G的数据(很多操作系统都已经抛弃了32位版本，所以这个也算不上什么缺点了，3.4版本已经放弃支持32 位 x86平台)

    Redis为什么是单线程：

　　单纯的网络IO来说，量大到一定程度之后，多线程的确有优势, 但并不是单纯的多线程，而是每个线程自己有自己的epoll这样的模型， 也就是多线程和multiplexing混合。但是。还要考虑Redis操作的是内存中的数据结构。如果在多线程中操作，那就需要为这些对象加锁。 所以使用多线程可以提高性能，但是每个线程的效率严重下降了，而且程序的逻辑严重复杂化。Redis的数据结构并不全是简单的Key-Value，  还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除一个对象，这些操作还可以合成MULTI/EXEC的组。这样一个操作中可能就需要加非常多的锁，导致的结果是同步开销大大增加。Redis在权衡之后的选择是用单线程，突出自己功能的灵活性。在单线程基础上任何原子操作都可以几乎无代价地实现，多么复杂的数据结构都可以轻松运用，甚至可以使用Lua脚本这样的功能。对于多线程来说这需要高得多的代价。

          并不是所有的KV数据库或者内存数据库都应该用单线程，比如ZooKeeper就是多线程的，最终还是看作者自己的意愿和取舍。单线程 的威力实际上非常强大，每核心效率也非常高，在今天的虚拟化环境当中可以充分利用云化环境来提高资源利用率。多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的，所以单线程、多进程的集群不失为一个时髦的解决方案。