JAVA面试——分布式缓存

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了JAVA面试——分布式缓存，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6508字，纯文字阅读大概需要10分钟。

内容图文

• 为什么用缓存？
• 高性能：减少查询同一个数据时的响应速度
• 高并发：减少数据库的承载压力（2000/s），缓存走内存，天然支撑高并发
• 缓存的不良后果：
• 缓存与数据库的双写不一致
• 缓存雪崩
• 缓存穿透
• 缓存并发竞争
• Redis和memcached区别（单线程、NIO、异步）
• Redis支持服务器端数据操作：数据类型更多，功能更全
• 内存使用效率对比：简单key-value时memcached效率高，hash结构存储Redis高
• 性能对比：Redis单线程,小数据时Redis高；大数据时多线程的memcached高
• 集群模式：memcached不支持集群，Redis支持
• Redis单线程模型：
• 文件事件处理器，单线程，通过IO多路复用程序同时监听多个socket，通过socket上的事件选择对应的事件处理器处理事件
• AE_READABLE：socket可读（连接操作、客户端对Redis执行write操作，close操作）
• AE_WRITABLE：socket可写（客户端对Redis执行read操作）

• Redis单线程模型为什么效率高？
• 纯内存操作（事件处理器在内存操作，性能高1ms）
• 核心基于非阻塞IO多路复用机制（不处理、直接压队列）
• 单线程避免了多线程的频繁上下文切换问题
• Redis有哪些数据类型？
• string
• hash
• 结构化数据，存放对象
• key=150
• value={
•   “id”: 150,
•   “name”: “zhangsan”,
•   “age”: 20
• }
• list
• 列表性数据结构（微博粉丝）
• key=某大v
• value=[zhangsan, lisi, wangwu]
• set
• 无需集合，自动去重
• sorted set
• 去重&排序
• Redis的过期策略、内存淘汰机制
• 定期删除+惰性删除
• 每隔100ms抽取设置过期时间的key，检查是否过期后删除（定期）
• 获取某个key时，redis检查是否过期（惰性）
• 内存淘汰

1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了 2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的） 3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的key给干掉啊 4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适） 5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key 6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除

• 手写LRU算法
• Redis高并发、高可用、缓存一致性：
• Redis高并发：主从架构，一主多从，单主用来写入数据，单机几万QPS，多从用来查询数据，多个从实例可以提供每秒10W的QPS。如果需要缓存容纳数据量大，用Redis集群。
• Redis高可用：如果你做主从架构部署，其实就是加上哨兵就可以了，就可以实现，任何一个实例宕机，自动会进行主备切换。
• 高并发
• 主从架构，实现读写分离（master写，slave读），水平扩容
• redis replication->主从架构->读写分离->水平扩容支撑读高并发
• master开启持久化
• 主从架构核心原理：
• master启动线程，生成RDB快照，发送给slave
• 断点续传，记录offset继续复制
• 无磁盘复制：在内存创建rdb，发送给slave
• Redis replication（复制）的完整流程
• 数据同步的核心机制：
• master和slave都会维护一个offset
• backlog：用来全量复制中断后的增量复制
• master run id：区分master（重启或者数据发生变化）
• psync：psync runid offset，从节点使用此命令从master node进行复制
• 全量复制
• master生成快照
• 发送给slave node
• master在生成快照时，将所有新的写命令缓存在内存中，slave保存rdb后，将新的写命令复制
• slave在接收到rdb后，清空旧数据，加载rdb
• 如slave开启aof，立即重写aof
• 增量复制
• 全量复制中断
• master用runid和offset从backlog中获取到丢失数据，发送给slave
• heartbeat
• master默认每隔10秒发送一次heartbeat，salve node每隔1秒发送一个heartbeat
• 异步复制
• master每次接收到写命令之后，现在内部写入数据，然后异步发送给slave node
• 高可用性
• 基于哨兵（sentinal）的高可用，故障转移（failover），主备切换
• 哨兵：
• 哨兵的作用：
1. 集群监控，负责监控redis master和slave进程是否正常工作
2. 消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
3. 故障转移，如果master node挂掉了，会自动转移到slave node上
4. 配置中心，如果故障转移发生了，通知client客户端新的master地址
• 分布式，哨兵集群运行
• 主备切换数据丢失问题：
• 异步复制导致：
• master->slave复制是异步的，可能没复制完，master宕机
• 集群脑裂导致：
• master主节点，出现异常性的相同工作的两个节点
• client可以和旧master写数据，恢复后旧master成为slave后数据丢失
• 解决：
• min-slaves-to-write 1
• min-slaves-max-lag 10
• 要求至少有1个slave，数据复制和同步的延迟不能超过10秒
• 如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了
• 哨兵的核心原理：
• sdown和odown转换：
• sdown主观宕机
• odown客观宕机
• quorum指定数量
• 哨兵的自动发现机制：
• __sentinel__:hello这个channel里发送一个消息
• slave配置的自动纠正
• slave->master选举算法
• 跟master断开连接的时长
• slave优先级
• 复制offset
• run id
• Redis重启数据恢复（数据持久化）
• 持久化的意义：数据备份、故障恢复
• 两种持久化：RDB、AOF
• RDB：对Redis中数据执行周期性的持久化
• AOF：对于每条写入命令作为日志，以append-only模式写入一个日志文件中（更加完整）
• Redis重启后，通过回放AOF日志中的指令重新构建数据集
• AOF大到一等程度后，rewrite操作，构建更小的AOF文件
• RDB优劣势：
• 优点：（冷备）
• 生成多个数据文件，适合冷备。AOF需要写脚本处理。
• RDB对Redis性能影响小，fork子进行进行RDB持久化
• RDB重启恢复速度快
• 缺点：
• 恢复效果差，数据丢失
• fork子进程时，数据文件特别大，会对客户端服务暂停数毫秒
• AOF优劣势：
• 优点：
• 保护数据不丢失
• append-only写入，没有磁盘寻址开销，写入性能高，文件不易损坏
• AOF日志文件过大rewrite对客户端读写性能影响小
• 日志文件可读
• 缺点：
• 日志文件大
• 支持的写QPS低
• 健壮性低
• 结合RDB和AOF同时使用
• Redis集群模式
• 分布式数据的核心算法，数据分布的算法：
• redis cluster——hash slot算法
• 每个master持有部分slot
• 节点间的内部通信机制
• 集群的元数据维护：集中式（ZooKeeper）、gossip
• gossip协议：元数据分散，降低压力，更新有延迟（meet ping pong fail）
• 10000端口：用于节点间通信，为服务接口+10000，ping->pong
• 交换信息的内容：故障信息、节点的增删、hash slot信息。。。
• jedis： Redis的java client客户端
• smart jedis：本地维护hashslot->node的映射表，缓存，不需要节点moved重定向
• hash tag手动指定对应slot，set key1:{100}
• 高可用与主备切换：
• pfail（主观宕机） fail（客观宕机）
• 与哨兵类似
• Redis缓存雪崩与缓存穿透
• 缓存雪崩：
• 事前：Redis高可用（主从+哨兵、Redis Cluster）
• 事中：本地ehcache缓存（系统内部小缓存）+hystrix限流（限流降级组件）
• 事后：Redis持久化，快速恢复缓存数据
• 缓存穿透：
• 没查到，写空值到缓存中（set -999 UNKNOWN）
• 使用布隆过滤器或者压缩filter提前拦截
• 缓存与数据库双写数据一致性（读写串行化）：
• 缓存+数据库读写模式：cache aside pattern
• 读。先缓存，再数据库，读完放入缓存
• 更新，先删除缓存（缓存复杂计算得到、不会频繁访问），再更新数据库
• 简单场景：先删缓存，在修改数据库
• 复杂场景（删除缓存，修改数据库之前，读后缓存旧数据，数据库新修改）
• 数据库与缓存更新读取操作进行异步（线程）串行化
• 内存队列放请求，一个队列对应一个线程，串行进行操作
• 读请求长时阻塞
• 队列里写请求过多（部署多个服务，分摊数据更新）
• 加多机器，每个机器上部署的服务实例处理更少的数据
• 多服务实例部署的请求路由
• 同一个商品的读写请求，路由到同一台机器上
• nginx，hash路由功能
• 热点商品的路由问题（读写请求高）
• 商品更新清空缓存，导致读写并发，更新频率不高影响不大
• Redis并发竞争问题：
• 多客户端并发写一个key
• CAS类的乐观锁方案
• zookeeper提供分布式锁
• 每个value的时间戳要比缓存中的时间戳更新，才可以写
• 生产环境中的Redis怎么部署

内容总结

以上是互联网集市为您收集整理的JAVA面试——分布式缓存全部内容，希望文章能够帮你解决JAVA面试——分布式缓存所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---