MySQL+Redis+网络+Linux+kafka+ES

【MySQL】

【问】sql语句？

https://blog.csdn.net/a_123456598/article/details/109249886

【问】where、having和on的区别？

where分组前的条件，不满足的查不出来；

having分组时的条件，查出来然后分组筛掉一部门。

on是连接表的条件。

【问】多表关系的实现？

【问】范式？

设计数据库时，需要遵从的一些规范，称为范式。要遵从后面的范式，必须遵从前面的范式。

数据库的备份：

【问】mysql和oracle的区别？

1.对事务的提交

• mysql中默认对事务进行提交，而oracle默认不提交，需要程序员自己去提交，commit

2.value，values

• 在mysql中，没有value的写法，在oracle中则是二者都可以实现，只不过在数据量越大时，value的执行更快

3.分页查询

• mysql中使用limit关键字进行分页查询，而oracle需要用到伪列ROWNUM和嵌套查询实现

4.类型和成本

• mysql是一个轻量级的关系型数据库，是开源免费的
• oracle是一个重量级的对象关系型数据库，是收费的

5.事务隔离级别

• mysql中默认的事务隔离级别为不可重复读，而oracle中默认的事务隔离级别为读已提交

【问】MyISAM 和 InnoDB的区别？

	INNODB（MySQL默认）	MYISAM
事务	支持	不支持
外键约束	支持，可多表操作	不支持
锁	行级锁	表级锁
全文索引	不支持	支持
性能、安全	性能低，安全性高	性能高，安全性低

 

 

 

 

 

 

【问】MySql索引原理？B树、B+树的结构？为什么B+树更好？Mysam和Innodb索引结构的区别？

（1）

Mysql使用的是B+树。

索引是帮助MySQL高效获取数据的排好序的数据结构，可以采取的数据结构有：Hash>>红黑树>>>B树>>>B+树。

（哈希表占内存，不能条件查询；红黑树太深，磁盘IO次数太多）

（2）

B树的结构？

B树，是一个多叉树，每个节点最多有K个节点，k的大小取决于磁盘页的大小。（在宽度上做文章，减小层数（h=3，减少磁盘IO次数））

B+树的结构？

相较于B树:

（1）B+树只在叶子节点存放data，非叶子节点存索引+指针。

（2）叶子节点为聚簇索引

（3）

Myisam引擎：

Innodb引擎（聚集索引，叶子节点放具体的数据）：

（4）b+树相比于b树的查询优势：

1.单个查询时候：

b+树的中间节点不保存数据，所以磁盘页能容纳更多节点元素，更“矮胖”；

b+树只要匹配到叶子节点然后划过去，可不用管元素位置，因此b+树查找更稳定（并不慢）；

2.范围查询时候：

b+树只需遍历叶子节点链表即可，b树却需要重复地中序遍历。

【问】主键、外键、索引、唯一索引？

	主键	外键	索引	唯一索引
定义	唯一标识一条记录，无重复，无空值	表的外键是另一个表的主键，可重复、可空值	允许重复，允许空值	无重复，可有一个空值
作用	保证数据完整性	和其他表建立联系	提升查询速度	提升查询速度+避免重复
个数	只能一个	可以有多个	可以多个	可以多个

 

 

 

 

 

【问】如何给数据库加索引？用索引？

加索引：

create index 索引名字 on 表名（字段名）;

用索引：

用索引进行条件查询。

select * from 表名 where 索引字段 = 条件值;

【问】什么时候索引失效？

1. 条件中有or + 有一个条件无索引（要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引）
2. like+左模糊（%写在了左边）
3. in 或 not in （如：select account from member where id in (1,2,3)  ，如果是连续数据，可以改为select account where id between 1 and 3;当数据较少时也可以参考union用法）
4. 使用！=或<>时
5. 如果mysql估计使用全表扫描要比使用索引快（数据量比较小）,则不使用索引（索引失效==全表扫描）

【问】Mysql索引查询比较慢？调优？

EXPLAIN。

【问】MySQL查询缓存？

（1）开启方式

a、my.cnf 加入以下配置，重启MySQL开启查询缓存

b、MySQL执行以下命令也可以开启查询缓存

（2）作用：

优点：

开启查询缓存后在同样的查询条件以及数据情况下，会直接在缓存中返回结果。

（缓存建立之后，MySQL的查询缓存系统会跟踪查询中涉及的每张表，如果这些表（数据或结构）发生变化，那么和这张表相关的所有缓存数据都将失效）

缺点：

缓存虽然能够提升数据库的查询性能，但是缓存同时也带来了额外的开销，每次查询后都要做⼀次缓存操作，失效后还要销毁。

注意：

因此，开启缓存查询要谨慎，尤其对于写密集的应用来说更是如此。如果开启，要注意合理控制缓存空间大小，⼀般来说其大小设置为几十MB比较合适。

此外，还可以通过 sql_cache和sql_no_cache来控制某个查询语句是否需要缓存。

【问】并发事务带来的问题？事务的隔离级别？

（1）三个预防难度递增的问题：

a、脏读：事务1还没结束，此时的数据是”脏数据“，被事务2所读取。

b、不可重复读：事务1多次读取数据，事务1还未结束，事务2修改数据，导致事务1读取的数据变化，不能够重复读取到正确的数据。

c、幻读：事务1读取了几行数据，事务2插入新数据，使得事务1读到了原本没有的记录，就像产生幻觉一样。

（2）四个隔离级别：

	脏读	不可重复读	幻读
读取未提交	有	有	有
读取已提交	无	有	有
可重复读	无	无	有
可串行化	无	无	无

 

 

 

 

 

 

innoDB默认的是可重复读，但有两个特殊点：

（1）安全：虽然是可重复读，但使用了Next-Key 锁算法，可以避免幻读的产生。

（2）性能：隔离级别越高，性能损失越大。但innoDB的可重复读相对于读取已提交没有性能损失。

在分布式事务的情况下，innoDB会用到可串行化隔离级别。

【问】数据库锁的作用？InnoDB锁算法？

（先去多线程文章理解一下java锁，搞懂java锁和数据库锁的区别。）

（1）数据库锁的作用就是解决数据库的并发问题，一般指的是事务并发。

（2）InnoDB的3种行锁算法：

1. Record lock：锁单行
2. Gap lock：锁一个范围，不包括本身。
3. Next-key lock：record+gap，锁一个范围，包括本身。（防止幻读）

【问】大表优化？

当MySQL单表记录数过大时，数据库的CRUD性能会明显下降，⼀些常见的优化措施如下：

（1）限定查询范围

禁止不带任何限制数据范围条件的查询语句。比如：当用户在查询订单历史的时候，我们可以控制在⼀个月的范围内；

（2）读写分离

a、拆分：分为两个不同的数据库服务器，主数据库提供写操作，从数据库提供读操作。

b、同步：当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性。

（3）分库分表

	分库分表前	分库分表后
并发支撑情况	MySQL 单机部署，扛不住高并发	MySQL从单机到多机，能承受的并发增加了多倍
磁盘使用情况	MySQL 单机磁盘容量几乎撑满	拆分为多个库，数据库服务器磁盘使用率大大降低
SQL 执行性能	单表数据量太大，SQL 越跑越慢	单表数据量减少，SQL 执行效率明显提升

a、垂直分区（最好分表）

把⼀张列比较多的表，拆分它的列，变成多张表。

b、水平分区（最好分库）

不改变表结构，把⼀张的表的数据拆成多张一样的表来存放。举个例：我们可以将⽤户信息表拆分成多个⽤户信息表，这样就可以避免单⼀表数据量过⼤对性能造成影响。

 

【问】池化设计思想？数据库连接池？

（1）池化设计思想

初始预设资源，抵消每次获取资源的消耗，如创建线程的开销、获取远程连接的开销等。

除了初始化资源，池化设计还包括如下这些特征：池子的初始值、池子的活跃值、池子的最大值等（池子的参数）。这些特征可以直接映射到java线程池和数据库连接池的成员属性中。

（2）数据库连接池

数据库连接：本质就是⼀个 socket 的连接。

数据库连接池：维护的数据库连接的缓存，以便将来需要对数据 库的请求时可以重⽤这些连接。好处：节约资源，节约时间。

【问】一条SQL语句在MySQL中式如何执行的？

MySQL主要分为 Server 层和引擎层：

（1）Server 层主要包括连接器、查询缓存、分析器、优化器、执行器，同时还有一个日志模块（binlog），这个日志模块所有执行引擎都可以共用。redolog 只有 InnoDB 有。

（2）引擎层是插件式的，目前主要包括，MyISAM,InnoDB,Memory 等。

SQL 执行过程分为两类：

（1）查询：权限校验---->>查询缓存---->>分析器---->>优化器---->>权限校验---->>执行器---->>引擎

（2）更新：分析器---->>权限校验---->>执行器---->>引擎---->>redo log prepare---->>binlog---->>redo log commit

【问】一条SQL执行的很慢的原因有哪些？

1、大多数情况下很正常，偶尔很慢（刷新脏页or遇到锁）

(1)数据库在刷新脏页，例如 redo log 写满了需要同步到磁盘。

(2)执行的时候，遇到锁，如表锁、行锁。

2、一直执行的很慢（没有用到索引：索引失效or选错了索引）

【问】MySQL锁？

1.五种锁：

S：LOCK IN SHARE MODE 共享锁

X：for update 排他锁

IS：意向共享锁

IX：意向排他锁

NK：间隙锁

2.读/写一行数据分别什么锁？

读/写一行数据加的锁，均和隔离级别有关，具体情况具体分析。

 

【Redis】

【问】Redis的持久化机制？过期策略？淘汰策略？

一、持久化机制

（1）RDB（快照+时间间隔）

每隔一个时间间隔按快照的形式保存到硬盘，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

（2）AOF（日志+写命令）

将Redis执行的每次写命令记录到单独的日志文件，写入硬盘。

（3）对比：

	RDB	AOF
安全性	相对不安全	相对安全（每条都记录）
恢复速度	快	慢

 

 

 

二、过期策略（过期时）

数据超过了设定的时间，不会被立即删除，而是存入过期字典。

惰性删除（被动）：

访问某个key，判定是否过期，过期就删除。

定期扫描（主动）：

从过期字典中随机抽取key，删除其中已经过期的key；若比例过高，再重复一次；

二、淘汰策略（内存不够时）

1. noeviction（默认淘汰策略）: 如果内存不足，直接报错；
2. allkeys-lru（常用的淘汰策略）：当内存不足的时候，移除最近最少使用的key；
3. allkeys-random：当内存不足的时候，随机移除key；
4. volatile-lru：当内存不足的时候，在设置了过期时间的所有key中，移除最近最少使用的key；
5. volatile-random：当内存不足的时候，在设置了过期时间的所有key中，随机移除key；
6. volatile-ttl：当内存不足的时候，在设置了过期时间的所有key中，优先删除有更早过期时间的key；

【问】Redis的5种基本数据结构？

【问】zset原理？

在set基础上加入了一个score字段，通过利用score和index来进行相关的排序。

【问】Redis3种缓存失效及其解决方式？

（1）缓存穿透

查询缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决：

1.布隆过滤器

将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力

2.缓存空对象

从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源；（空白值键浪费内存）

（2）缓存击穿

缓存击穿是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。（缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。）

解决：

把热点数据设置为永远不过期。

（3）缓存雪崩

缓存雪崩是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决：

1.缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。

2.一般并发量不是特别多的时候，使用最多的解决方案是加锁排队。

3.给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。

【问】Reids的集群模式？

（1）主从模式：

是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。

主从复制的作用

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3. 负载均衡：可以实现读写分离（延迟与不一致问题，数据过期），可以由主节点提供写服务，由从节点提供读服务，分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

【数据同步阶段】全量复制和增量复制

• 全量复制：

用于初次复制或其他无法进行增量复制的情况，将主节点中的所有数据都发送给从节点，是一个非常重型的操作。主节点收到全量复制的命令后，执行bgsave，在后台生成RDB文件，并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令。执行完毕后，将RDB文件发给从节点，从节点清楚旧数据，执行写命令更新数据。

• 部分复制：

用于处理主从复制中因网络闪断原因造成的数据丢失场景，当从主节点再次连接上主节点后，如果（条件允许），主节点会补发丢失数据给从节点。因为补发的数据远远小于全量数据，可以有效避免全量复制的过高开销，需要注意的是，如果网络中断时间过长，造成主节点没有能够完整的保存中断期间执行的写命令，则无法进行部分复制，仍使用全量复制。主节点有一个ID设置偏移量，主节点有一个ID，恢复的时候如果是原本的ID，就增量，如果不是就全量。

（2）哨兵机制：

实现自动化的故障恢复；不过只能实现主节点的故障切换恢复，无法对从节点实现故障恢复。进一步提高了Redis的高可用性。

原理：

主节点会被多个哨兵节点监控，当主节点发生故障宕机挂掉了，哨兵节点通过心跳检测判断其出现故障下线了（主观下线），如果判断下线的哨兵节点超过一定数量，则判断为客观下线，通过Raft算法（先到先得）来协商出一个领导哨兵节点进行故障转移操作，选出一个从节点升级为主节点，原来的主节点会变成新主节点的从节点。 缺点：哨兵无法对从节点进行自动故障转移

怎么选择从节点的？

1、先过滤掉那些不健康的从节点 2、根据优先级选择（slave-priority值越小越好，设为0则没有机会） 3、无法区分优先级，根据复制偏移量大的来（offset） 4、无法区分复制偏移量，则选择运行ID最小的

配置哨兵节点需要注意的地方？

1、配多几个哨兵节点，并且部署在不同物理机上，防止误判主节点故障 2、配置个数最好为奇数，容易‘决策’

 

【问】Redis的分布式锁？

1、怎么实现？

使用SET NX命令：

当且仅当 key 不存在，将 key 的值设为 value。 若给定的 key 已经存在，则 SET NX 不做任何动作。

（Redis采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系）

set key value [EX seconds] [PX milliseconds] [NX|XX]
EX seconds：设置失效时长，单位秒
PX milliseconds：设置失效时长，单位毫秒
NX：key不存在时设置value，成功返回OK，失败返回(nil)
XX：key存在时设置value，成功返回OK，失败返回(nil)

案例：设置name=p7+，失效时长100s，不存在时设置
1.1.1.1:6379> set name p7+ ex 100 nx
OK
1.1.1.1:6379> get name
"p7+"
1.1.1.1:6379> ttl name
(integer) 94
del key 解锁

2、Redis实现分布式锁的原则？

1. 独享
2. 无死锁
3. 容错

【问】Redis为什么这么快？

1.内存

2.数据结构简单

3.单线程+多路复用技术=非阻塞IO/NIO（单线程速度很快，又保证了多线程的特点）（没有多线程和锁切换的消耗）

 

【网络】

【问】计算机网络各层作用？

（1）应用层：通过应用进程间的交互来完成特定网络应用。（每个应用就是一个进程）（HTTPS、DNS、SMTP、FTP、Telnet、RIP、NFS）

（2）传输层：负责向两台主机进程之间的通信提供通用的数据传输服务。（TCP/UDP）

（3）网络层：选择合适的网络路由和交换结点， 确保数据及时传送。（IP、ICMP、ARP、RARP）

（4）链路层：数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。

（5）物理层：实现相邻计算机节点之间⽐特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。

【问】请你说一说IP地址作用，以及MAC地址作用？

MAC地址（链路层）：是一个硬件地址，用来定义网络设备的位置。

IP地址（网络层）：是IP协议提供的一种统一的地址格式，为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。

【问】URI和URL？

• URI：资源的号码
• URL：资源的路径

【问】http和https区别？（应用层）

HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP传输层之上。

	https	http
安全性	安全（相对于http，使用ssl身份认证和加密传输）	不安全（超文本传输协议=明文传输协议）
资源消耗	高	低
费用	收费（ca申请证书）	免费
默认端口	443	80

 

 

 

 

 

【问】请你说一说HTTP返回码。

HTTP协议的响应报文：

1xx：指示信息--表示请求已接收，继续处理。

2xx：成功--表示请求已被成功接收、理解、接受。

3xx：重定向--要完成请求必须进行更进一步的操作。

4xx：客户端错误--请求有问题（不合法或找不到）

5xx：服务器端错误--请求合法，服务端有问题。

【问】GET和POST的区别？（应用层Http的请求）

	GET	POST
安全性	不安全，因为URL地址栏显示数据内容。	安全，URL不显示数据内容。
性能	高效	不高效
携带参数量	比较少，大小有限制	大小没有限制

 

 

 

 

【问】Cookie和Session的区别？

cookie和session都是保存会话的技术。常见场景：网站登录之后，你下次不用再登录了，第二次访问直接就上去了！

a、cookie是客户端技术 （客户端携带）（不安全，如果携带敏感信息要加密）

b、session是服务器技术（ 保存在服务器）（安全）

【问】SSL握手？

SSL握手过程

目的： 

1. 客户端与服务器需要就一组用于保护数据的算法达成一致； 
2. 它们需要确立一组由那些算法所使用的加密密钥； 
3. 握手还可以选择对客户端进行认证。

 过程： 

1. 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器； 
2. 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数； 
3. 客户端对服务器的证书进行验证(有关验证证书，可以参考数字签名)，并抽取服务器的公用密钥；然后，再产生一个称作pre_master_secret的随机密码串，并使用服务器的公用密钥对其进行加密(参考非对称加/解密)，并将加密后的信息发送给服务器； 
4. 客户端与服务器端根据pre_master_secret（随机密码串）以及客户端与服务器的随机数值独立计算出加密和MAC密钥(参考DH密钥交换算法)。 
5. 客户端将所有握手消息的MAC值发送给服务器； 
6. 服务器将所有握手消息的MAC值发送给客户端。

【问】什么时候用UDP？TCP和UDP的区别？

1.UDP的应用

速度要求快，允许丢包，不需要建立连接的时候。

比如：游戏、直播、物联网。

2.TCP和UDP的区别？

	TCP	UDP
是否面向连接	面向连接（一对一），保证可靠	不面向连接（可以一对多、多对多），不保证可靠
首部开销	大（20字节）	小（8字节）
面向	字节流（文件传输）	报文

 

 

 

 

 

【问】TCP如何保证可靠性？

（1）检验和：

TCP 将保持它首部和数据的检验和。这是⼀个端到端的检验和，目的是检测数据 在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报⽂段和不确认收 到此报文段。

（2）流量控制（滑动窗口）：

TCP 连接的每⼀⽅都有固定大小的缓冲空间，TCP的接收端只允许发送端发送 接收端缓冲区能接纳的数据。当接收⽅来不及处理发送⽅的数据，能提示发送⽅降低发送的 速率，防⽌包丢失。

（3）拥塞控制： 

1. 慢启动: 先发送少量的数据,逐渐增大。
2. 拥塞避免: 让拥塞窗口缓慢增长,按线性规律。
3. 快重传+快恢复: 接收失效报文,立即发出重复确认,让发送方重新发送,不要发送数据时捎带。

（4）确认再发（ARQ）

等对方确认再发。

（5）超时重传。

【问】三次握手、四次挥手？四次挥手为什么是四次？

（1）

                       

（2）

（在建立连接的时候,Server把响应客户端的请求和请求客户端的确认放在一起发送给客户端了,即第二次握手时有SYN+ACK）

断开连接的时候,一个方向允许断开，但另一个方向可能还有数据正在传，所以ACK和FIN要分开发。

【问】http1.0 和 http2.0的区别？

HTTP2.0和HTTP1.X相比的新特性

1.文本 -> 二进制格式（鲁棒性）：

HTTP1.0：

解析是基于文本。（文本的表现形式有多样性，要考虑的场景很多才能做到健壮性）

HTTP2.0：

协议解析决定采用二进制格式，实现方便且健壮。

2.HTTP2.0比HTTP1.0有路复用：

即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

3.header压缩：

HTTP1.x的header带有大量信息，而且每次都要重复发送，

HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

4.服务端推送：

HTTP2.0也具有server push功能。

附注：

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？

HTTP/1.* 一次请求 - 响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；

HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

具体如图：

【问】输入网址后到页面加载，发生了什么？

1.域名解析（ip网络层）

2.建立TCP连接。（传输层）

3.HTTP或HTTPS请求（GET或POST）。（应用层）

4.响应，返回URL

（或错误信息；如果设定重定向，则重定向到新的URL地址）

URL是什么？

URL是Internet 上标准的资源地址。包括：协议+域名（ip）+资源位置+参数

5.客户端浏览器下载数据，解析HTML源文件

（解析的过程中实现对页面的排版，解析完成后，在浏览器中显示基础的页面。）

6.分析页面中的超链接

（显示在当前页面，重复以上过程直至没有超链接需要发送，完成页面的全部显示）

 

【Linux】

ls，pwd，cd，mkdir，touch，sudo...

【kafka】

【问】消息队列的作用？

（1）异步处理：响应速度快

消息队列中保存一定的信息，因此发送注册邮件+发送注册短信是很快的。

（2）应用解耦

（3）流量削锋

【问】为什么用Kafka？

与RocketMQ、RabbitMQ 对比。

1. 性能 ：

基于 Scala 和 Java 语言开发，设计中大量使用了批量处理和异步的思想，最高可以每秒处理千万级别的消息。

2. 兼容性：

Kafka 与周边生态系统的兼容性是最好的没有之⼀，尤其在大数据和流计算领域。

【问】kafka的组成？

发布-订阅模式（解决多个消费者的问题）

Broker>Topic>Partion

事件为一个Broker，点赞、关注、评论为三个不同的Topic。

【问】如何保证不重复消费？

 

【问】防止信息丢失？

 

【ES】