Dubbo和Spring
Cloud并不是完全的竞争关系，两者所解决的问题域不一样：Dubbo的定位始终是一款RPC框架，而Spring Cloud的目的是微服务架构下的一站式解决方案。
非要比较的话，Dubbo可以类比到Netflix OSS技术栈，而Spring Cloud集成了Netflix OSS作为分布式服务治理解决方案，但除此之外Spring Cloud还提供了包括config、stream、security、sleuth等分布式服务解决方案。
当前由于RPC协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时Dubbo与Spring Cloud只能二选一，这也是两者总拿来做对比的原因。
Dubbo之后会积极寻求适配到Spring Cloud生态，比如作为SpringCloud的二进制通讯方案来发挥Dubbo的性能优势，或者Dubbo通过模块化以及对http的支持适配到Spring Cloud
redis和memcache的区别
1、 Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等等。
2、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。
3、虚拟内存--Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘
4、过期策略--memcache在set时就指定，例如set key1 0 0 8,即永不过期。Redis可以通过例如expire 设定，例如expire name 10
5、分布式--设定memcache集群，利用magent做一主多从;redis可以做一主多从。都可以一主一从
6、存储数据安全--memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）
7、灾难恢复--memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复
8、Redis支持数据的备份，即master-slave模式的数据备份。
redis穿透：正常的执行路径是这样的，请求数据，首先会从redis缓存中拿数据，如果缓存没有的话才去查数据库，再写到redis缓存中。那么如果有人请求一条根本不存在的数据时，redis里面肯定没有嘛，它就会去访问数据库，但是数据库没有，所以它也没把数据写回redis缓存。所以它每次请求这个数据的时候它就会直接去访问数据库。如果请求的数量太大的话，都直接穿过redis直接去访问数据库，数据库承受不了这个访问数量。
解决办法：在redis里面用一个set集来把数据库查询的那个查询主键都读出来存到这个set集里面。如果有请求时，先查redis里面的set有没有这个主键，如果没有就直接返回，不查数据库。如果有的话查redis，如果没有的话才去查数据库并把数据库里的数据写到缓存中。
redis雪崩：每个key（即数据）如果设置了失效时间的话，如果大量key同时过期的时候，这些key又大量地去请求这些key时，因为redis里面没有这些数据，就会大量的请求就会大量涌向数据库，就会导致数据库处理不过来，导致“雪崩”。
解决办法：在设置失效时间的时候，给它加一个随机的秒数（0~60），来让这些大量的数据进行错开对数据库的访问。这样数据库就能应付过来了。如果这个key的访问频率频繁的时候，我们可以让它每查一次就给它加点有效时间。这样就能解决雪崩问题了
