网站开发与设计英文书籍,普通网站和门户网站的区别,中国企业信息公示网登录,购物网站开发uml图常用消息中间件及其测试方法 一、中间件的使用场景引入中间件的目的一般有两个#xff1a;1、提升性能常用的中间件#xff1a;1) 高速缓存#xff1a;redis2) 全文检索#xff1a;ES3) 存日志#xff1a;ELK架构4) 流量削峰#xff1a;kafka 2、提升可用性产品架构中高可… 常用消息中间件及其测试方法 一、中间件的使用场景引入中间件的目的一般有两个1、提升性能常用的中间件1) 高速缓存redis2) 全文检索ES3) 存日志ELK架构4) 流量削峰kafka 2、提升可用性产品架构中高可用设计1) 分布式锁redis2) 数据分布式存储rediseskafka 二、Redis1、redis 的数据同步策略以及数据一致性保证2、哨兵模式的设计架构如何理解读写分离选举和脑裂1、什么是哨兵2、哨兵的配置文件3、网络分区故障网络故障1master节点和哨兵节点出现网络故障2master节点和slave节点出现网络分区故障 4、脑裂是什么怎么解决 3、缓存失效下的熔断和降级以及测试方法1、造成缓存失效的几种情况2、采取的应对策略3、 如何模拟redis缓存失效 4、缓存击穿下的处理方法和测试方法1、什么是缓存击穿2、缓存击穿解决方案 5、缓存穿透下的测试方法1、什么是缓存穿透2、缓存穿透的解决方案3、如何测试 6、淘汰缓存还是更新缓存1、缓存操作方式1读操作流程2写操作流程淘汰缓存 or更新缓存3写操作先淘汰缓存再更新数据库 or 先更新数据库再淘汰缓存 7、缓存雪崩的测试方法1、如何处理雪崩2、如何模拟雪崩 三、Kafka1、kafka的两个常用场景2、为什么要用消息队列3、和其他消息队列相比kafka的优势在哪里4、队列模型了解吗Kafka 的消息模型知道吗5、什么是Producer、Consumer、Broker、Topic、Partition6、Kafka 的多副本机制了解吗带来了什么好处7、Zookeeper 在 Kafka 中的作用知道吗8、Kafka 如何保证消息的消费顺序9、Kafka 如何保证消息不重复消费10、如何测试kafka 一、中间件的使用场景
引入中间件的目的一般有两个 1、提升性能 产品架构中的性能设计 常用的中间件 1) 高速缓存redis 基于内存所以比mysql块存在磁盘io为什么查询速度快 单进程IO多路复用去提高性能基于内存 做缓存极大缓解了数据库压力非常适合读多写少的场景 2) 全文检索ES 适用于大量搜索的场景用的倒排索引应对读多写少的场景mysql用的正序索引应对写多读少的场景 3) 存日志ELK架构 logstash收集日志目前已经被filebeat替代然后存入es再通过kibana展示 4) 流量削峰kafka 目前最流行的消息中间件 2、提升可用性 产品架构中高可用设计 1) 分布式锁redis 应用场景解决高可用设计中多实例部署下数据访问加锁的问题 2) 数据分布式存储rediseskafka 自身就有非常好的高可用设计都是集群可以分布式部署集群中一台挂了其他机器也能继续提供服务。数据保存到这些软件也是分布式部署可以保证都有相应备份即使一台挂了其他机器也可以对外提供服务也可以确保机器更加安全。
二、Redis
1、redis 的数据同步策略以及数据一致性保证
现在软件架构非常复杂面对数以万计的qps的情况下如果单台机器到达性能瓶颈需要一种横向扩展策略希望把用户请求用负载均衡方式分布在其他机器分担压力。当把所有数据分布到不同机器时候如何保证每一台机器的数据是完全一致的呢 为了提升性能必须使用集群部署比如我们现在要一主两从架构进行部署我们可以把写请求发送到主节点把读请求发送到从节点以降低主节点的压力读写分离的意义。如果保证主从节点的数据是一致的呢我们就需要数据同步策略异步同步
2、哨兵模式的设计架构如何理解读写分离选举和脑裂
1、什么是哨兵
哨兵是redis官方推荐的集群高可用解决方案它能够自动识别redis集群的健康状态并在master节点异常时将从节点提升为master节点
2、哨兵的配置文件 3、网络分区故障
高可用测试最常注入的故障类型之一 网络故障 1master节点和哨兵节点出现网络故障 1、出现在master节点和哨兵节点之间。比如用户和master节点是正常的但是master和哨兵节点连接不上会造成哨兵认为master挂了开始新一轮选举过程。 2、这样会导致节点出现2个master节点都可以接受请求导致脑裂。 3、所以哨兵必须集群状态部署当其中一个哨兵认为master节点是下线状态会给master节点标记主观下线状态但是被标记后master节点仍然可以对外提供服务哨兵也不会重新选举master。 4、只有其他哨兵也认为主节点挂了这时候才会触发只有当xx哨兵认为主节点是下线状态它才会被标记为客观下线状态哨兵重新选举的功能 2master节点和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和partitiontopic主题消费者可以通过订阅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推荐发送消息的时候我们可以发送topicpartitionkeydata四个参数。如果指定partition的话kafka可以把消息发送到指定的partition。并且同一个key的消息可以保证只发送到一个partition
9、Kafka 如何保证消息不重复消费
根本原因消息已经消费了但是没有提交offset 处理方案 消费方做幂等校验比如redis分布式锁mysql的主键等 enable.auto.commit设置成false改成手动提交offset
10、如何测试kafka
因为功能上出问题的概率不大我们测试需要做的就是模拟producer到brokerbroker到consumer之间的各种故障再验证数据是否完整有没有数据丢失或者重复 比如网络抖动一下后producer推送到broker的数据丢失怎么办一般来说会做retry操作比如重试3次如果3次都失败了那么可能broker本身有问题或者网络问题抛异常是可以的。但是retry有副作用假设当producer推送数据给brokerbroker已经保存到本地之后把响应返回给producer的时候失败了这时候再retry就会导致broker重复保存数据到本地存储造成数据重复 如何解决这个问题呢 kafka有专门的包把producer变成幂等的producer判断是否消息之前推送过如果是的话就不会进行第二次存储。这个是如何实现的呢就是根据消息生成idproducer会把消息id一起推送到brokerbroker根据消息的id和本地存储数据进行对比就可以知道消息是否重复。但是这个也有缺陷就是只对单broker有用多broker/partition是不行的kafka有分布式事务的producer保证broker不会重复保存数据。producer开了分布式事务以后consumer也要做改动要把消息读取变成committed read只会去读取已经提交的事务只是提供了框架里面的逻辑是自己写的包括consumer怎么维护offset状态producer里事务怎么提交
