常用中间件redis，kafka及其测试方法

一、中间件的使用场景

引入中间件的目的一般有两个：

• 1、提升性能

  • 产品架构中的性能设计：

  • 常用的中间件：

    • 1) 高速缓存：redis

      • 基于内存，所以比mysql块（存在磁盘io）
      • 为什么查询速度快？
        • 单进程+IO多路复用去提高性能
        • 基于内存
      • 做缓存，极大缓解了数据库压力
      • 非常适合读多写少的场景

    • 2) 全文检索：ES

      • 适用于大量搜索的场景
      • 用的倒排索引，应对读多写少的场景
      • mysql用的正序索引，应对写多读少的场景

    • 3) 存日志：ELK架构

      • logstash收集日志（目前已经被filebeat替代），然后存入es，再通过kibana展示
        

    • 4) 流量削峰：kafka

      • 目前最流行的消息中间件

• 2、提升可用性

  • 产品架构中高可用设计：

  • 1) 分布式锁：redis

    • 应用场景：解决高可用设计中多实例部署下数据访问加锁的问题
      

  • 2) 数据分布式存储：redis，es，kafka

    • 自身就有非常好的高可用设计，都是集群，可以分布式部署，集群中一台挂了，其他机器也能继续提供服务。数据保存到这些软件，也是分布式部署，可以保证都有相应备份，即使一台挂了，其他机器也可以对外提供服务，也可以确保机器更加安全。

二、Redis

1、redis 的数据同步策略以及数据一致性保证？

• 现在软件架构非常复杂，面对数以万计的qps的情况下，如果单台机器到达性能瓶颈，需要一种横向扩展策略，希望把用户请求用负载均衡方式分布在其他机器分担压力。当把所有数据分布到不同机器时候，如何保证每一台机器的数据是完全一致的呢？
  
• 为了提升性能，必须使用集群部署，比如我们现在要一主两从架构进行部署，我们可以把写请求发送到主节点，把读请求发送到从节点，以降低主节点的压力（读写分离的意义）。如果保证主从节点的数据是一致的呢，我们就需要数据同步策略（异步同步）
  
  

2、哨兵模式的设计架构，如何理解读写分离，选举和脑裂

1、什么是哨兵？

• 哨兵是redis官方推荐的集群高可用解决方案
• 它能够自动识别redis集群的健康状态并在master节点异常时将从节点提升为master节点

2、哨兵的配置文件

3、网络分区故障

• 高可用测试最常注入的故障类型之一

• 网络故障：

• 1）master节点和哨兵节点出现网络故障：

  • 1、出现在master节点和哨兵节点之间。比如用户和master节点是正常的，但是master和哨兵节点连接不上，会造成哨兵认为master挂了，开始新一轮选举过程。
    
  • 2、这样会导致节点出现2个master节点都可以接受请求，导致脑裂。
    
  • 3、所以哨兵必须集群状态部署，当其中一个哨兵认为master节点是下线状态，会给master节点标记主观下线状态，但是被标记后master节点仍然可以对外提供服务，哨兵也不会重新选举master。
    
  • 4、只有其他哨兵也认为主节点挂了，这时候才会触发（只有当xx哨兵认为主节点是下线状态，它才会被标记为客观下线状态）哨兵重新选举的功能
    

• 2）master节点和slave节点出现网络分区故障：

  • 导致master节点数据没有同步到slave节点，会出现数据不一致的问题，用户读取的是旧数据
  • 如果这个时候master节点也挂了，slave会变为master，会出现数据彻底的丢失的问题，所以连接不上的时候会禁止写请求
    

4、脑裂是什么，怎么解决？

• 脑裂就是出现网络分区故障后，同时存在多个master节点。
• 解决方案：
  • 1、master节点连接不上哨兵节点：只有多个哨兵标记它为主观下线状态，它才会真正的下线
  • 2、master节点连接不上slave节点：就会禁止写操作

3、缓存失效下的熔断和降级以及测试方法

• 1、造成缓存失效的几种情况？

  • 缓存过期
  • 缓存更新：更新缓存一般采用淘汰更新，这个时候缓存取不到，就会去数据库里面取，再更新缓存。这就造成有极短的一段时间内，缓存是失效的
  • redis异常
  • 网络异常

• 2、采取的应对策略？

  • 禁用某些接口，只开放核心接口：非核心接口用户一请求，就直接返回异常。保证缓存失效时候核心接口可以继续工作
  • 禁用某些服务
    

• 3、 如何模拟redis缓存失效？

  • 1）你需要输入出系统的核心服务列表和服务中的核心接口列表。
  • 2）注入故障，然后验证（非核心接口去访问时候应该是拒绝的）
    • 直接把redis下线
    • 注入一个网络故障
      • 比如可以用iptables模拟断网故障，tc模拟延迟故障，也可以去下载阿里开源工具chaos-blade，下载后一条命令就可以模拟故障

4、缓存击穿下的处理方法和测试方法

• 1、什么是缓存击穿？

  当redis中的某个热key（比如首页广告）过期或者因为某些异常原因导致无法从缓存中读取，导致大量的并发访问数据库而崩溃

• 2、缓存击穿解决方案？

  • 首先要和运维沟通，确认线上哪些key是热key。如果不知道哪些key是热key，我们压测的时候，可以使用比较大的并发去压，然后登录到redis，手动删除这条缓存，人为模拟热key过期的场景，再看系统的反应，会不会触发熔断和降级策略
  • 对于固定热key可以不设置失效时间，通过人工手动去维护
  • 利用熔断和降级策略，同上
    • 禁用某些接口，只开放核心接口：非核心接口用户一请求，就直接返回异常。保证缓存失效时候核心接口可以继续工作
    • 禁用某些服务
      

5、缓存穿透下的测试方法

• 1、什么是缓存穿透？

  数据既不存在在缓存中，也不存在在数据库中。常见一些网络攻击场景以及前端逻辑错误时发生。

• 2、缓存穿透的解决方案？

  • 采用布隆过滤器
    • 误判率。布隆过滤器有一定的误判率，但这种误判通常发生在未曾添加到过滤器中的元素上。对于已添加的元素，过滤器能正确判断其存在与否。
    • 预校验。在查询数据前，可以先使用布隆过滤器进行预校验，判断数据是否可能存在。如果数据不存在，可以直接返回空结果，避免了对底层存储系统的不必要访问。
  • 如果一个查询返回的数据为空，不管数据是否存在或系统故障，都把空的数据进行缓存，只不过过期时间比较短。这样下一次查询就有数据可以返回

• 3、如何测试？

  通过接口请求方式发送不存在缓存和数据库的查询请求，验证系统是否可以处理大量既不存在在缓存中，也不存在在数据库中的数据。

6、淘汰缓存还是更新缓存

• 1、缓存操作方式

  redis是高速缓存组件，需要跟数据库进行频繁交流才能让缓存生效。缓存操作方式就需要一定的步骤和规则，如果出错，就会导致出现bug

  • 1）读操作流程？

    • 先查询redis，如果redis有数据，就直接返回redis数据
    • 如果redis没有数据，就从数据库中读取数据
      • 读取数据库是有延迟的，是比较慢的操作，所以在高并发下，可能不仅有一次的读请求会从数据库中读取数据。因为假如说我们第一个请求过来之后，它还没有完成把数据库的数据更新到redis缓存的时候，其他并发也过来了，就会导致在一个比较瞬时的状态的时候，会有相当多的读数据库的请求出现
    • 从数据库读取数据后，更新redis缓存

  • 2）写操作流程：淘汰缓存 or更新缓存？

    • 淘汰缓存
      • 优点是操作简单
      • 缺点是淘汰后下一次请求就会读取数据库
    • 更新缓存
      • 数据库更新完了之后，就会更新缓存的内容。
      • 优点是不会出现下一次cache miss
      • 缺点是代价比较大（比如更新操作涉及到好几张表，会导致性能差，延缓更新缓存时间。如果在更新的时候其他的读请求进来了，会造成数据不一致的情况，可能会读到旧的数据）
    • 结论：淘汰缓存作为通用方案

  • 3）写操作：先淘汰缓存再更新数据库 or 先更新数据库再淘汰缓存？

    • 先更新数据库：如果更新数据库后还没来得及淘汰缓存服务就挂掉了，那么就会出现脏数据
    • 先淘汰缓存：如果淘汰缓存后更新数据库之前的这段时间有其他的读请求发送过来，就会把老数据读取到redis缓存中
      • 但是他在复杂场景下还是可能遇到数据不一致问题，比如写操作出现问题，比如所在磁盘io特别高，导致写缓存和更新数据库操作比较慢，可能会出现如下问题，当把淘汰缓存执行完还没有更新数据库的时候，另一个请求过来读取缓存，取的仍然是旧的值
        
    • 结论：先淘汰缓存，可以使用延迟双删策略弥补缺陷
      • 延迟双删是什么？
        • 1）先删除缓存
        • 2）再写数据库
        • 3）休眠500毫秒（根据具体业务时间来定）
        • 4）再次删除缓存
          

  7、缓存雪崩的测试方法

  当redis中大量缓存在一个较短的时间内全部过期，导致于在一个瞬间时间内大量的请求直接访问数据库，造成数据库崩溃

  • 1、如何处理雪崩？

    • 一般会采用熔断或降级策略。
      • 禁用某些接口，只开放核心接口：非核心接口用户一请求，就直接返回异常。保证缓存失效时候核心接口可以继续工作
      • 禁用某些服务

  • 2、如何模拟雪崩？

    • 弄挂redis服务，比如在redis和服务之间注入网络分区故障，让服务连接不上redis，看看服务是否熔断或降级
    • 写一个接口，把redis常用的缓存删了

  三、Kafka

  1、kafka的两个常用场景？

  • 1） 流量削峰
    • 先将短时间高并发产生的事务消息存储在消息队列中，然后后端服务再慢慢根据自己的能力去消费这些消息，这样就避免直接把后端服务打垮掉
  • 2） 流计算
    • 大数据处理的一种
      

  2、为什么要用消息队列？

  • 1、通过异步处理提高系统性能（减少响应所需时间）
  • 2、降低系统耦合性：生产者（客户端）发送消息到消息队列中去，接收者（服务端）处理消息，需要消费的系统直接去消息队列取消息进行消费即可而不需要和其他系统有耦合，也提高了系统的扩展性。
  • 3、流量削锋：先将短时间高并发产生的事务消息存储在消息队列中，然后后端服务再慢慢根据自己的能力去消费这些消息，这样就避免直接把后端服务打垮掉。

  3、和其他消息队列相比，kafka的优势在哪里？

  • 1、极致的性能：最快可以每秒处理千万级别的数据
  • 2、和其他生态系统的兼容性好：Kafka 与周边生态系统的兼容性是最好的没有之一，特别是在大数据和流计算领域
  • Kafka 主要有两大应用场景：
    • 消息队列 ：建立实时流数据管道，以可靠地在系统或应用程序之间获取数据。
    • 数据处理： 构建实时的流数据处理程序来转换或处理数据流。

  4、队列模型了解吗？Kafka 的消息模型知道吗？

  早期的队列模型就是生产者把消息发到消息队列，然后消费者从消息队列去取消息，但是这样做有个弊端，就是如果这个消息需要发送给多个消费者，每个消费者都要收到完整的内容，这种情况队列模型就不好解决了。kafka用的是发布订阅的消息模型，用topic作为消息载体，相当于是广播模型。只要生产者把消息发到topic里，该条消息通过主题传递的方式通知所有的消费者

  5、什么是Producer、Consumer、Broker、Topic、Partition？

  • producer：生产者，生产消息的人
  • consumer：消费者，消费消息的人
  • broker：代理，相当于kafka的实例，多个broker可以构成一个cluster[ˈklʌstə®]（集群），broker里面包含topic和partition
  • topic：主题，消费者可以通过订阅topic来消费消息
  • partition：分区，一个topic里面可以有多个分区
    

  6、Kafka 的多副本机制了解吗？带来了什么好处？

  每个分区里都有多个副本，副本里面又有一个leader副本和多个follower副本，follower副本是从leader副本里面拉取消息进行同步，相当于leader副本的拷贝。当leader副本出现问题的时候，会从follower副本里面选取新的leader。生产者和消费者只和leader副本做交互。
  好处：
  • 1、一个topic里有多个partition，然后一个partition可以在多个broker里，这样可以提升并发能力（负载均衡）
  • 2、因为partition可以指定副本数量，这样可以提升消息存储的安全性，但是同时也相应的增加了存储空间

7、Zookeeper 在 Kafka 中的作用知道吗？

• 1、broker注册：每个broker启动时候，会到zookeeper进行注册
• 2、topic注册：同一个topic会分成多个分区，并将其分布到多个broker，这些分区和broker对应关系由zookeeper记录
• 3、负载均衡：对于同一个topic里有多个partition，当生产者产生消息后，kafka会尽力的将一个partition投递到多个broker里，当消费者消费的时候，zookeeper会根据当前消费者数量和broker数量来实现动态负载均衡

8、Kafka 如何保证消息的消费顺序？

因为kafka里消息是存放在partition里，而且每次添加消息到partition里都是采用尾追法，kafka只能保证partition里的消息有序。消息被添加到partition的时候都会分配一个特定的偏移量来保证顺序。
这个时候我们就有2种方式来保证消费顺序

• 1、一个topic里只对应一个partition（不推荐）
• 2、发送消息的时候指定key/partition（推荐）：发送消息的时候我们可以发送topic，partition，key，data四个参数。如果指定partition的话，kafka可以把消息发送到指定的partition。并且，同一个key的消息可以保证只发送到一个partition

9、Kafka 如何保证消息不重复消费？

根本原因：消息已经消费了，但是没有提交offset
处理方案：
消费方做幂等校验，比如redis分布式锁，mysql的主键等
enable.auto.commit设置成false，改成手动提交offset

10、如何测试kafka？

• 因为功能上出问题的概率不大，我们测试需要做的就是模拟producer到broker，broker到consumer之间的各种故障，再验证数据是否完整，有没有数据丢失或者重复
  • 比如网络抖动一下后，producer推送到broker的数据丢失怎么办？一般来说会做retry操作，比如重试3次，如果3次都失败了，那么可能broker本身有问题，或者网络问题，抛异常是可以的。但是retry有副作用，假设当producer推送数据给broker，broker已经保存到本地之后，把响应返回给producer的时候失败了，这时候再retry就会导致broker重复保存数据到本地存储，造成数据重复
    
  • 如何解决这个问题呢？
    • kafka有专门的包把producer变成幂等的producer（判断是否消息之前推送过，如果是的话就不会进行第二次存储。）这个是如何实现的呢，就是根据消息生成id，producer会把消息+id一起推送到broker，broker根据消息的id和本地存储数据进行对比就可以知道消息是否重复。但是这个也有缺陷，就是只对单broker有用，多broker/partition是不行的
    • kafka有分布式事务的producer，保证broker不会重复保存数据。producer开了分布式事务以后，consumer也要做改动，要把消息读取变成committed read（只会去读取已经提交的事务）只是提供了框架，里面的逻辑是自己写的，包括consumer怎么维护offset状态，producer里事务怎么提交