ToB企服应用市场:ToB评测及商务社交产业平台

标题: 常用中央件redis，kafka及其测试方法 [打印本页]

---

作者: 祗疼妳一个    时间: 2024-8-8 22:20
标题: 常用中央件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里变乱怎么提交
      
    
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4