Redis 相关
你们为什么使用redis？
答： 我们的数据库主要用的是MySQL，目前的业务发展设计到高并发场景下的库存扣减，网站首页访问流量高峰等等，数据库已经支撑不住如此高的并发，于是我们引入了缓存中间件，市面上的中间件redis和memcached我们有在用。我在使用过程中对reids和memcached做了下对比：
1） redis相比memcached来说用拥有更多的数据结构和支持更丰富的数据操作。 所以像我们公司设计复杂的结构和操作，我们选择了redis
2) 在内存使用效率上做了下对比，单纯使用key-value 存储的话，memcached的内存利用率更高，但redis采用hash结构来做key-value 存储，由于其组合式的压缩，让内存的利用率高于了memcached
3) 在性能上， redis只使用单核，而memcached 可以使用多核，所以平均每一个核上的redis在存储小数据时比memcached性能要高。
在使用过程中，有时候也设计到100K以上的数据，这个时候，redis的性能就稍逊于memcached
3） 在数据持久化支持上，redis提供了两种持久化策略，分别是RDB快照和AOF日志，而memcached 不支持数据持久化操作。
所以综合下来我们选择了redis。
redis有哪些数据类型
答： 关于redis的数据类型，我知道的有这么几个： 字符串string，字典hash, 列表list, 集合set , 有序集合 SortedSet，因为公司涉及到高并发，所以还接触过Bloom Filter，以及支持全文搜索的RediSearch等。
redis是怎么做持久化的？
答： 持久化有两种方式RDB和AOF，RDB做镜像全量持久化，AOF做增量持久化。 我们公司一般RDB和AOF会配合起来使用。 在redis实例重启的时候，会使用RDB持久化文件重构内存，在使用AOF重放近期的操作指令来恢复重启前的状态。
当然reids的机制是AOF开启且存在AOF文件时候，优先加载AOF文件。 AOF关闭或者AOF文件不存在的时候，加载RDB文件。
大流量的时候不要开AOF，开RDB即可
如果服务器突然断电，可以使用AOF恢复，AOF日志有sync属性配置，在高性能场景下使用定时sync，比如1s1次，这样即使断电最多丢失1s的数据。
redis有哪些应用场景
1） 存储json类型的对象
2）排行榜， 计数器
3） 优酷视频的点赞
4）朋友圈点赞
5）会话缓存
redis哨兵模式原理
原理：客户端来连接集群时，会首先连接 sentinel，通过 sentinel 来查询主节点的地址，然后再连接主节点进行数据交互。当主节点发生故障时，客户端会重新向 sentinel 索要主库地址，sentinel 会将最新的主库地址告诉客户端。通过这样客户端无须重启即可自动完成节点切换。
哨兵模式当中涉及多个选举流程采用的是 Raft 算法的领头选举方法的实现；
Redis 主从复制、哨兵和集群这三个有什么区别？
1.主从模式：读写分离，备份，一个Master可以有多个Slaves。
2.哨兵sentinel：监控，自动转移，哨兵发现主服务器挂了后，就会从slave中重新选举一个主服务器。
3.集群：为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS不受限于单机，可受益于分布式集群高扩展性。
Redis主从数据库的配置？
master slave
主不用配置，从redis的conf文件加入 slaveof ip port 就可以了
Redis 哨兵模式配置
修改 sentinel.cnf 文件
# sentinel 只需指定检测主节点就行了，通过主节点自动发现从节点
sentinel monitor mymaster 127.0.0.1 6379 2
# 判断主观下线时长
sentinel down-after-milliseconds mymaster 30000
# 指定可以有多少个Redis服务同步新的主机，一般而言，这个数字越小同步时间越长，而越大，则对网络资源要求越高
sentinel parallel-syncs mymaster 1
# 指定故障切换允许的毫秒数，超过这个时间，就认为故障切换失败，默认为3分钟
sentinel failover-timeout mymaster 180000redis 哨兵状态常用命令：
1. 查看redis是否是集群模式，info cluster 命令
2. 查看集群的所有节点信息，cluster nodes 命令
3. 查看集群中各个节点的slot区间，cluster slots 命令
4. 查看指定key所在slot的值，cluster keyslot key 命令
redis是怎么做持久化的？
答： 持久化有两种方式RDB和AOF，RDB做镜像全量持久化，AOF做增量持久化。 我们公司一般RDB和AOF会配合起来使用。 在redis实例重启的时候，会使用RDB持久化文件重构内存，再使用AOF重放近期的操作指令来恢复重启前的状态。
当然reids的机制是AOF开启且存在AOF文件时候，优先加载AOF文件。 AOF关闭或者AOF文件不存在的时候，加载RDB文件。
大流量的时候不要开AOF，开RDB即可
如果服务器突然断电，可以使用AOF恢复，AOF日志有sync属性配置，在高性能场景下使用定时sync，比如1s1次，这样即使断电最多丢失1s的数据。
介绍下kafka 工作原理？
答：Kafka 的工作原理主要包括以下几个方面。首先，Kafka 是一个分布式的消息队列系统。它由多个 Broker 组成，每个 Broker 可以理解为一个独立的服务器节点。Kafka 的数据存储以主题（Topic）为单位，每个主题又被分为多个分区（Partition），数据就存储在这些分区中。分区在不同的 Broker 上进行分布，实现了数据的分布式存储和负载均衡。
生产者（Producer）负责向 Kafka 发送消息，它可以决定将消息发送到指定主题的某个分区。在发送消息时，生产者可以采用同步或异步的方式，并可以设置消息的序列化方式和分区策略。
消费者（Consumer）从 Kafka 读取消息。消费者通过订阅主题来获取消息，并且可以以组（Consumer Group）的形式协同工作。同一组内的消费者可以共同消费同一个主题的不同分区，实现了消息的并行处理。Kafka 通过维护消费者组的偏移量（Offset）来记录消费者已经消费的位置。
Kafka 还依赖于 ZooKeeper 进行协调管理，例如保存 Broker 信息、主题和分区的元数据等。
您解决 Kafka 遇到的问题、排查步骤和最终的解决方案？
答案：有一次，Kafka 出现消息堆积的情况。表现为消费者处理速度明显慢于生产者发送速度，监控指标显示堆积量持续增加。
排查步骤首先检查了消费者的代码逻辑，未发现异常。然后查看了 Kafka 的配置，发现分区数量设置不合理。最终解决方案是增加了分区数量，并优化了消费者的处理逻辑，提高了消费能力，解决了消息堆积问题。
问了下MySQL数据库cpu飙升到500%怎么处理？
列出所有进程 show processlist 观察所有进程 多秒没有状态变化的(干掉)
查看超时日志或者错误日志 (做了几年开发,一般会是查询以及大批量的插入会导致cpu与i/o上涨, 当然不排除网络状态突然断了,,导致一个请求服务器只接受到一半，比如where子句或分页子句没有发送,当然的一次被坑经历)
如何从mysqldump产生的全库备份中只恢复某一个库、某一张表？
全库备份
mysqldump -uroot -p --single-transaction -A --master-data=2 >dump.sql
只还原erp库的内容
mysql -uroot -pMANAGER erp --one-database <dump.sql
可以看出这里主要用到的参数是--one-database简写-o的参数，极大方便了我们的恢复灵活性
Keepalived的工作原理？如何做健康检查？
答：在一个虚拟路由器中，只有作为MASTER的VRRP路由器会一直发送VRRP通告信息, BACKUP不会抢占MASTER。当MASTER不可用时(BACKUP收不到通告信息)，多台BACKUP中优先级最高的这台会被抢占为MASTER。这种抢占是非常快速的（<1s），以保证服务的连续性；由于安全性考虑，VRRP包使用了加密协议进行加密。BACKUP不会发送通告信息，只会接收通告信息。
keepalived主要有三个模块，分别是core、check和vrrp。
core模块为keepalived的核心，负责主进程的启动、维护及全局配置文件的加载和解析。
check负责健康检查，包括常见的各种检查方式，
vrrp模块是来实现VRRP协议的；
发现nacos 服务注册不上，如何解决？
回答：
当遇到 Nacos 服务注册不上问题时，我会采取以下步骤来逐步排查和解决：
1. 检查 Nacos 服务端状态：
我首先会确认 Nacos 服务是否正常运行，可以通过 ps -ef | grep nacos 检查进程是否存在。
同时查看 Nacos 的日志文件，通常在 $NACOS_HOME/logs/nacos.log 目录下，查看是否有错误信息或异常堆栈。
2. 确认 Nacos 控制面板：
通过浏览器访问 Nacos 控制面板，默认地址是 http://<NACOS_SERVER_IP>:8848/nacos，登录后检查服务列表页是否有相关的服务信息。
3. 检查网络连接：
- 确保服务实例能够访问 Nacos 服务端。我会使用 ping 和 telnet 命令测试连通性：
- ping <NACOS_SERVER_IP> 确认网络是否可达。
- telnet <NACOS_SERVER_IP> 8848 确认端口是否开放。
- 同时检查防火墙或安全组设置，确保没有阻止服务实例和 Nacos 之间的网络通信。
4. 确认 Nacos 客户端配置：
- 我会检查服务实例的 Nacos 客户端配置文件，确保配置了正确的 Nacos 服务端地址。例如，在 Spring Cloud 中，通过 application.properties 或 application.yml 配置：
server-addr: ${NACOS_SERVER_IP}:8848
7. 查看详细日志：
我会设置更详细的日志级别来捕获调试信息。在 application.properties 中配置日志级别：
logging.level.com.alibaba.nacos=DEBUG
logging.level.com.alibaba.cloud=DEBUG
分析详细日志信息，寻找具体的错误和异常堆栈，以定位问题根源。
8. 检查数据库连接（如果 Nacos 使用外部数据库）：
确权数据库连接是否正常，例如确保在 application.properties 中配置了正确的数据库连接信息：
db.url.0=jdbc:mysql://<MYSQL_SERVER_IP>:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
db.user=nacos
db.password=nacos
确保数据库账号和权限配置正确，数据库和表已经正确创建。
Nacos 作为服务发现和配置管理组件，其稳定运行是非常关键的。常见问题和解决方法包括：
服务启动失败：检查端口、数据库连接、内存和权限。
集群节点无法通信：检查网络连通性、配置文件和 DNS 配置。
控制台无法访问：确保服务已启动、防火墙和反向代理配置正确。
配置无法同步：统一数据库配置，确保集群通信正常，解决 MySQL 主从同步问题。
变更策略优化：采用批量变更、灰度发布和监控报警策略。
评论区