所以除了“透明大页与传统HugePages联用会出现一些问题，导致性能问题和系统重启外，上面这两点是Redis建议关闭THP的更重要的原因。
1、Redis中，并不是所有的数据都一直存储在内存中的，这是和Memcached相比一个最大的区别。 Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。
2、Redis跟memcache不同的是，储存在Redis中的数据是持久化的，断电或重启后，数据也不会丢失。
3、数据类型支持不同 与Memcached仅支持简单的key-value结构的数据记录不同，Redis支持的数据类型要丰富得多。最为常用的数据类型主要由五种：String、Hash、List、Set和Sorted Set。
4、性能 都比较高，性能对我们来说应该都不是瓶颈。总体来讲，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。操作的便利性 memcache 数据结构单一。
5、总的来说Redis作者是一位非常勤奋的开发者，可以经常看到作者在尝试着各种不同的新鲜想法和思路，针对这些方面的功能就要求我们需要深入了解后再使用。 总结： Redis使用最佳方式是全部数据in-memory。
1、Redis的哨兵机制就是解决主从复制存在缺陷（选举问题），解决问题保证我们的Redis高可用，实现自动化故障发现与故障转移。 要使用哨兵机制，除了启动Redis服务以外，还要启动哨兵服务来进行监控，会介绍详细步骤。
2、Redis主从复制是指在一个Redis集群中，将一个Redis节点作为主节点，其余的Redis节点作为从节点。主节点负责写入数据，从节点负责读取数据。
3、哨兵模式解决了故障不能自动恢复的问题，但仍存在的问题是：Redis较难支持在线扩容，对于集群，容量达到上限时在线 扩容会变得很复杂 。
4、这个哨兵模式才稳定下来，无论是主从模式，还是哨兵模式，这两个模式都有一个问题，不能水平扩容，并且这两个模式的高可用特性都会受到Master主节点内存的限制。
5、redis高可用：如果你做主从架构部署，其实就是加上哨兵就可以了，就可以实现，任何一个实例宕机，自动会进行主备切换。
redis主要消耗内存物理资源。Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
内存限制：Redis是基于内存的存储系统，当缓存数据量过大时，可能会消耗大量内存资源，影响软件其他功能的性能。缓存穿透、缓存击穿和缓存雪崩：这些现象可能导致缓存系统承受较大压力，进而影响整个软件的性能和稳定性。
我们在使用Redis的时候，String 类型是我们使用最多的，他也是唯一的一个非集合类型。然而String类型并不是适用于所有场合的，它有一个明显的短板，就是它保存数据时所消耗的内存空间较多。
虽然内存及时释放，但是十分消耗 CPU 资源。在大并发请求下，CPU 要将时间应用在处理请求，而不是删除 Key，因此没有采用这一策略。定期删除+惰性删除如何工作定期删除，Redis 默认每个 100ms 检查，有过期 Key 则删除。
原因如下：json数据本身通常比纯文本数据占用更多的存储空间，因为它包含了更多的元数据和结构信息。redis存储的所有数据都是存在内存中的，包括json数据，因此如果大量存储json数据会占用较多的内存。
第一，单线程简化算法的实现，并发的数据结构实现不但困难且测试也麻烦。第二，单线程避免了线程切换以及加锁释放锁带来的消耗，对于服务端开发来说，锁和线程切换通常是性能杀手。
本文暂时没有评论，来添加一个吧(●'◡'●)