自带的数据结构：不用和缓存服务器建立通信，效率可能会更高？但是在集群环境数据不能共享。
redis可以持久化，服务器重启不用重新建立缓存
redis是单线程，线程安全的。 自带的要考虑线程安全的问题.
引用知乎上面的原话是：
问“哪种好”一般得到的答案都是“不一定”。这不是一个非黑即白的世界，大部分时候还得要“看情况”。
轻量级应用自带数据结构做缓存可以是一个不错的选择，不通过网络的通讯方式肯定相对高效，并且对程序来说也简单易用。但是大部分自带数据结构并不是线程安全的，意味着在适当的时候你需要自己加锁进行线程同步。线程同步的话题不在本题的讨论范围内，但是想玩转线程同步也并不是件轻松的事情，很多人不是锁不住就是使用过重的锁导致性能低下。在真正高并发环境中哪怕一小段时间的性能下降，也可能导致服务器上累积大量请求无法处理而使应用崩溃。
所以当你的应用到达一定规模，就该考虑使用分布式缓存了，除了锁的问题已经在服务端解决之外，还可以解决你提到的缓存无法共享的问题，以及水平扩展的问题（缓存太多无法在一台服务器容纳怎么办？）。同样的条件下从内部缓存迁移到分布式缓存可能并不能缩短响应时间提高QPS，大部分时候可能还会在一定程度上延长响应时间（网络传输及序列化、反序列化过程）。但是作为交换，更重要的是带来了水平扩展能力，说直白些，让你可以通过堆服务器就可以处理更多请求。水平扩展才是大部分分布式数据库要解决的重点问题。
当然在引入NoSQL的同时也不可避免地引入了复杂性，为你的开发增加额外的工作量。但是NoSQL数据库又会带来一些额外的好处，比如高可用，缓存数据的一致性。
说了这么些恐怕已经绕晕了，我想表达的意思是，引入NoSQL来做缓存可能并不像你想象的那么美妙，它既会带来问题，也会带来优势。你要做的事情是，对你自己的应用场景评估它带来的优势是不是你想要的，享受这些优势的同时，你是否可以容忍它带来的不良影响，然后决定要不要用。
如果redis水平扩展时，要注意主从延迟的问题，如果业务要求高一致性， 就只能都从主