Redis是啥？
想要了解Redis，先从Redis是什么？为何要用Redis？有哪些特性，以及其集群架构来几个方面来了解。Redis 简介Redis 是一个开源（BSD 许可）的、内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。为什么要用 Redis在高并发场景下，如果需要经常连接结果变动频繁的数据库，会导致数据库读取及存取的速度变慢，数据库压力极大。
因此我们需要通过缓存来减少数据库的压力，使得大量的访问进来能够命中缓存，只有少量的需要到数据库层。由于缓存基于内存，可支持的并发量远远大于基于硬盘的数据库。所以对于高并发设计，缓存的设计是必不可少的一环。而 Redis 作为比较热门的内存存储系统之一，由于其对数据持久化的支持，种类丰富的数据结构，使其定位更倾向于内存数据库，适用于对读写效率要求都很高、数据处理业务复杂和对安全性要求较高的系统。
Redis 特征单线程，利用 redis 队列技术将访问变为串行访问，消除了传统数据库串行控制的开销。Redis 的线程模型：Redis 支持数据的持久化，包括 RDB 的全量持久化，或者 AOF 的增量持久化，从而使得Redis 挂了，数据是有机会恢复的。也可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。
分布式架构，读写分离。支持的数据结构丰富。Redis 不仅仅支持简单的 key-value 类型的数据，同时还提供 list、set、zset、hash 等数据结构的存储。Redis 支持数据的备份，提供成熟的主备同步，故障切换的功能，从而保证了高可用。Redis Cluster 架构Redis 搭建方式有很多种，本章主要介绍 Redis Cluster 集群构建方式：Redis 3.0 之后版本支持 Redis Cluster 集群，Redis Cluster 采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。
Redis Cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的 SORT 就可以由从服务器来承担。
redis有哪些数据类型？
Redis中的所有 value 都是以 Object 的形式存在的，其通用结构如下：typedef struct redisObject {unsigned [type] 4;unsigned [encoding] 4;unsigned [lru] REDIS_LRU_BITS;int refcount;void *ptr;} robj;type：指类型，String、Hash、List、Set、ZSet；encoding：类型具体的实现方式；比如 Set 是用 hashTable 实现还是 intSet 实现；lru：最后一次被访问的信息，其实一看到 LRU 估计也就和淘汰策略有关；refcount：对象引用计数；ptr：指向实际实现者的地址；StringRedis 中的 String 不仅仅表示 字符串，还可以表示 整型、浮点型。
String 的编码可以是 int、raw 或者 embstr；单说普通的字符串，就有 raw 和 embstr 两种实现方式，embstr 是 Redis 3.0 新增的数据结构：字符串长度小于 39 字节，就用 embstr 对象，否则用传统的raw对象（Redis 3.2版本之后，这里变成了以 44 字节为分界）。
embstr 的优势在于创建时少分配一次空间（RedisObject 和 sds 是连续的），删除时少释放一次空间，以及对象的所有数据连在一起，寻找方便；当然缺点也非常明显，如果字符串的长度增加，需要重新分配内存的时候，整个 RedisObject 和 sds 都需要重新分配空间。修改 embstr 对象的时候，Redis 会将其转换成 raw 格式再进行修改，所以 embstr 对象修改之后的对象，一定是 raw 的。
应用场景：常规计数都可以使用，可用作缓存、计数、限速等等，比如商品剩余数量，字典表信息，长度不能超过 512MB。HashHash 对象的底层实现可以是 ziplist 或者 hashtable。ziplist：在这个数据结构中，是按照 key1, value1, key2, value2 这样的顺序存放来存储的；hashTable：是由 dict 这个结构来实现的。
（这个结构比较复杂，后面单写一篇来说）应用场景：Hash 适用于存储结构化的对象，可以直接修改这个对象中的某个字段的值；比如用户信息。ListList 对象的编码可以是 ziplist 或者 linkedlist，从名字上也能看出来两种结构都是啥。ziplist：是一种压缩链表，它存储数据都是连续地放在内存区域当中。
linkedlist：是一种双向链表。应用场景：通常网站上的消息列表，可以使用 List 来进行存储；另外 lrange 命令，从某个元素开始，读取多少个元素，可以看做是分页查询，比如很多网站上那种不断下拉，不断分页的效果。SetSet 相对于 List 来说，Set 是可以自动排重的；它的编码可以是 intset 或者 hashtable 。
intset：是一个整数集合，支持三种长度的整数：int16_t、int32_t、int64_t；集合中的数据长度必须是一致的，比如一个 int16_t 长度的 Set，当插入了一条 int32_t 长度的数据，那么所有的数据都会转成 int32_t 长度（不支持降级）。hashTable：对于 Set 来说，hashTable 的 value 永远为 NULL。
应用场景：如果要存储一个列表，同时又需要做数据排重的时候，可以使用 set ；另外，Redis 还为 Set 提供了求交集、并集、差集等操作，比如微博上面的【共同关注】这个功能，就可以用 Set 实现。ZSet / Sorted Set和 Set 相比，ZSet 增加了一个参数 score，集合中的元素按照 score 进行有序排列。
有序集合的编码可能两种，一种是 ziplist，另一种是 skipList 与 hashTable 的结合。ziplist：和 Hash 类似，元素 和 score 都是按顺序存放的；比较适合用于元素内容不大的场景。skipList hashTable：是一种添加，移除，更新元素等操作更高效的数据结构，这个跳跃表的数据结构，我近期会发一篇文章单独介绍。
有些程序员一直坚持反对使用redis怎么办？
分享大佬的回答，似乎很有道理。不要告诉我们用不用redis，你得告诉我们你为什么想要用redis，不用redis业务会有什么问题？天下没有免费的午餐，不动脑子直接上缓存/NOSQL可能会带来更多更严重的问题。单一数据库最大的好处在于事务性实现简单，由数据库自己保证。举个简单的例子，下订单需要扣除一个库存，然后插入一条订单条目，如果库存和订单都是数据库表项的话这个事务是无懈可击的，如果库存在redis里，订单条目是MySQL，通常就需要先写redis，成功之后再写数据库，如果写数据库失败了还需要回滚redis，如果最后这个回滚因为网络之类的原因失败了，就会多扣一个库存。
memcache、redis、mongodb优缺点是什么啊,怎么选？
虽然都是nosql范畴，但是memcache、redis主要设计目的是做缓存使用mongodb的核心是提供无模式文档结构的持久化存储，它的两个核心点：提供接近（其实差距挺大的）缓存服务器的速度和接近关系数据库API（这个已经差不多了，连接查询是弱点）的接口。memcache、redis如果是几年前，memcache、redis之间还有选择综合症，目前的市场，你可以直接选择redis，把精力完全放在redis身上去深入。
这是是市场反应，这个相信对你的选择有绝对说服力。memcache在性能方面没有优势了，同时redis提供了更丰富的数据结构，各种原子操作，以及持久化（RDB/AOF）。如果你是小规模项目，你甚至可以直接用它设计消息订阅，使用它的即时消息订阅发布（你有消息持久化需求的话可以额外用redis的列表功能等定制）。
mongodb相比redis和memcache，mongodb的性能差距就比较大了。mongodb最核心的是它提供的B树索引，这个为我们提供了范围查询的基础，4.0提供了事务后，才算真正可以勉强在某些场合替代关系数据库。动态性和内嵌设计后的便利操作，很适合做中间数据管理。PS：我最先使用mongodb，其实主要是用它做LBS应用。
mongodb,redis,hbase，三者都是nosql数据库，他们的最大区别和不同定位是什么？
一、NoSQL的简介NoSQL比关系型数据库性能高数倍。NoSQL凭借 “易扩展、大数据、高可用、高性能、灵活性”特点强势引领全场。CP型分布式数据库，能够保证数据的强一致性和分区容忍性。二、NoSQL的常用种类1、mongodb优点:MongoDB最大的特点是表结构灵活可变，字段类型可以随时修改。MongoDB是高性能、无模式的文档型数据库，文件存储格式为BSON(二进制格式的JSON),支持二级索引，在事务、复杂查询应用下无法取代关系型数据库。
支持相比于HBase更复杂的集合查找。简而言之，往MySQL写数据像是在做填空题，你写入的数据必须与最早定义的表结构一致，而往MongoDB写数据就像是在做问答题，想怎么写就怎么写，这灵活度不要爽太多。缺点：比较消耗内存，有事务、join（全外连接）等短板。因此，如果你的数据的逻辑结构非常复杂，经常需要进行复杂的多表查询或者事务操作，那显然还是MySQL这类关系型数据库更合适。
使用场景:得益于MongoDB的这些特点，MongoDB很适合那些表结构经常改变，数据的逻辑结构没又没那么复杂不需要多表查询操作，数据量又比较大的应用场景。2、redisRedis是现在最热门的key-value数据库，是内存亦可持久化的日志型，读写性能最强。提供五种数据类型：String，hash，list，set及zset(sorted set)。
适合存储全局变量和高效的分布式缓存。当内存达到一定的阈值，数据可以定时持久化到硬盘中。优点:Redis的最大特点当然就是key-value存储所带来的简单和高性能了。适合读多写少的业务场景，支持操作原子性。缺点:不支持二级索引。也不适合做存储和分析。因此Redis无法提供常规数据库所具备的多列查询、区段查询等复杂查询功能。
同时，由于Redis需要把数据存在内存中，因此数据量要小于HBase与MongoDB。应用场景:Redis牺牲了常规数据库中的数据表、复杂查询等功能，换来了很大的性能提升，特别适合那些对读写性能要求极高，且数据表结构简单（key-value、list、set之类）、查询条件也同样简单的应用场景。如果你的数据表结构还挺复杂，你还经常需要做一些复杂查询操作，那你最好还是老老实实用MongoDB或者SQL吧。
3、HbaseHBase是Hadoop项目的一部分,HBase列式数据库，BigTable的一种实现。高效存储大量数据，支持列压缩，行事务。适合Schema-less的数据，适合稀疏表，一个表可以容纳上亿行、上百万列，用做超大数据量要求扩展简单的离线分析型应用。Hadoop的无缝集成，有数据可靠性和海量数据分析性能（MapReduce）的能力。
优点:HBase也继承了Hadoop项目的最大优点，那就是对海量数据的支持，以及极强的横向（存储容量）扩展能力。缺点:HBase的列式存储特性带来了海量数据规模的支持和极强的扩展能力，但是也给数据的读取带来很大的局限。由于只有同一列族的数据才会被存放在一起，而且所有的查询都必须要依赖Key，这就使得很多复杂查询难以进行。
应用场景:作为MapReduce（大规模数据集（大于1TB）的并行运算）的后台数据源；Facebook的消息类应用，包括Messages、Chats、Emails和SMS系统，用的都是HBase。综上所述:如果你对数据的读写要求极高，并且你的数据规模不大，也不需要长期存储，选redis；如果你的数据规模较大，对数据的读性能要求很高，数据表的结构需要经常变，有时还需要做一些聚合查询，选MongoDB；如果你需要存储海量数据，连你自己都不知道你的数据规模将来会增长多么大，那么选HBase。
