*1.SOA架构:*
系统间的直接调用(RPC方案)
*2.消息队列,MQ模型*
sender ———> 消息队列 ——–> receiver
1.无侵入,接耦合
2.提高系统响应时间,异步执行
*3.消息队列类型:*
1.点对点 ①queue中不存储已经消费的消息,不持久化 ②有多个消费者,点对点只支持一个消费者
2.发布订阅 将消息发布到topic中,所有订阅该topic的消费者都能消费消息
*4.消息队列MQ对比*
RabbitMQ:支持的协议多,非常重量级消息队列,对路由(Routing),负载均衡(Load balance)或者数据持久化都有很好的支持。
ZeroMQ:号称最快的消息队列系统,尤其针对大吞吐量的需求场景,擅长的高级/复杂的队列,但是技术也复杂,并且只提供非持久性的队列。
ActiveMQ:Apache下的一个子项,类似ZeroMQ,能够以代理人和点对点的技术实现队列 。
Redis:是一个key-Value的NOSql数据库,但也支持MQ功能,数据量较小,性能优于RabbitMQ,数据超过10K就慢的无法忍受
*5.kafka简介:*
1.分布式 2.可划分(patition)3.多订阅者 4.持久化 5.处理流式数据(实时数据)
*6.kafka是跟zk配套使用的*
*7.日志持久化*
1. 日志是存于topic中的,同时kafka会对topic分区,切分成若干个partition,类似于自己在数据库中创建一张表
2. 一个topic对应一个consumer group
*8.kafka逻辑架构图*
*9.kafka校验机制*
Kafka没有采用ack的机制,消息丢了就丢了,采用的是CRC校验机制
*10.kafka的消息状态记录*
消息状态记录是由zk来记录的。
*11.kafka的borker无状态机制*
1. Broker没有副本机制,一旦broker宕机,该broker的消息将都不可用。
Broker不保存订阅者的状态,由订阅者自己保存。
无状态导致消息的删除成为难题(可能删除的消息正在被订阅),kafka采用基于时间的SLA(服务水平保证),消息保存一定时间(通常为7天)后会被删除。
消息订阅者可以rewind back到任意位置重新进行消费,当订阅者故障时,可以选择最小的offset(id)进行重新读取消费消息。
*12.partition的三个属性*
1. offset 对应类型 long
2. messagesize 对应类型 int32
3. data 是message的具体内容
**其中2和3是作为CRC机制校验规则的参数使用