2024年Java最新Day256，京东java面试流程

最后

看完上述知识点如果你深感Java基础不够扎实，或者刷题刷的不够、知识不全面

小编专门为你量身定制了一套<Java一线大厂高岗面试题解析合集：JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法>

针对知识面不够，也莫慌！还有一整套的<Java核心进阶手册>，可以瞬间查漏补缺

全都是一丢一丢的收集整理纯手打出来的

更有纯手绘的各大知识体系大纲，可供梳理：Java筑基、MySQL、Redis、并发编程、Spring、分布式高性能架构知识、微服务架构知识、开源框架知识点等等的xmind手绘图~

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

分布式的nosql数据库，hbase，分布式的协调，zookeeper，分布式通用计算引擎，spark，分布式的实时计算引擎，storm

如果你要处理海量数据，就涉及到了一个名词，叫做大数据，只要涉及到大数据，那么其实就会涉及到分布式

redis cluster，分布式

因为我来讲java系统的架构，有时候跟其他人不一样，纯搞java，但是我因为工作时间很长，早期专注做java架构，好多年，大数据兴起，就一直专注大数据系统架构

大数据相关的系统，也涉及很多的java系统架构，高并发、高可用、高性能、可扩展、分布式系统

会给大家稍微拓展一下知识面，从不同的角度去讲解一块知识

redis，高并发、高性能、每日上亿流量的大型电商网站的商品详情页系统的缓存架构，来讲解的，redis是作为大规模缓存架构中的底层的核心存储的支持

高并发、高性能、每日上亿流量，redis持久化 -> 灾难的时候，做数据恢复，复制 -> 读写分离，扩容slave，支撑更高的读吞吐，redis怎么支撑读QPS超过10万，几十万; 哨兵，在redis主从，一主多从，怎么保证99.99%可用性; redis cluster，海量数据

java架构课，架构思路和设计是很重要的，但是另外一点，我希望能够带着大家用真正java架构师的角度去看待一些技术，而不是仅仅停留在技术的一些细节的点

给大家从一些大数据的角度，去分析一下我们java架构领域中的一些技术

天下武功，都出自一脉，研究过各种大数据的系统，redis cluster讲解了很多原理，跟elasticsearch，很多底层的分布式原理，都是类似的

redis AOF，fsync

elasticsearch建立索引的时候，先写内存缓存，每秒钟把数据刷入os cache，接下来再每隔一定时间fsync到磁盘上去

redis cluster，写可以到任意master，任意master计算key的hashslot以后，告诉client，重定向，路由到其他mater去执行，分布式存储的一个经典的做法

elasticsearch，建立索引的时候，也会根据doc id/routing value，做路由，路由到某个其他节点，重定向到其他节点去执行

分布式的一些，hadoop，spark，storm里面很多核心的思想都是类似的

后面，马上把redis架构给讲完之后，就开始讲解业务系统的开发，包括高并发的商品详情页系统的大型的缓存架构，jedis cluster相关api去封装和测试对redis cluster的访问

jedis cluster api，就可以自动针对多个master进行写入和读取

2、实验不同master各自的slave读取 -> 读写分离

---

在这个redis cluster中，如果你要在slave读取数据，那么需要带上readonly指令，get mykey1

redis-cli -c启动，就会自动进行各种底层的重定向的操作

---

实验redis cluster的读写分离的时候，会发现有一定的限制性，默认情况下，redis cluster的核心的理念，主要是用slave做高可用的，每个master挂一两个slave，主要是做数据的热备，还有master故障时的主备切换，实现高可用的

---

redis cluster默认是不支持slave节点读或者写的，跟我们手动基于replication搭建的主从架构不一样的

slave node，readonly，get，这个时候才能在slave node进行读取

redis cluster，主从架构是出来，读写分离，复杂了点，也可以做，jedis客户端，对redis cluster的读写分离支持不太好的

默认的话就是读和写都到master上去执行的

如果你要让最流行的jedis做redis cluster的读写分离的访问，那可能还得自己修改一点jedis的源码，成本比较高

要不然你就是自己基于jedis，封装一下，自己做一个redis cluster的读写分离的访问api

核心的思路，就是说，redis cluster的时候，就没有所谓的读写分离的概念了

读写分离，是为了什么，主要是因为要建立一主多从的架构，才能横向任意扩展slave node去支撑更大的读吞吐量

---

redis cluster的架构下，实际上本身master就是可以任意扩展的，你如果要支撑更大的读吞吐量，或者写吞吐量，或者数据量，都可以直接对master进行横向扩展就可以了

也可以实现支撑更高的读吞吐的效果

不会去跟大家直接讲解的，很多东西都要带着一些疑问，未知，实际经过一些实验和操作之后，让你体会的更加深刻一些

redis cluster，主从架构，读写分离，没说错，没有撒谎

redis cluster，不太好，server层面，jedis client层面，对master做扩容，所以说扩容master，跟之前扩容slave，效果是一样的

3、实验自动故障切换 -> 高可用性

---

redis-trib.rb check 192.168.109.101:7001

比如把master1，101:7001，杀掉，看看它对应的102:7004能不能自动切换成master，可以自动切换

[root@s1 init.d]# ps -ef|grep redis

[root@s1 init.d]# kill -9 1176

[root@s1 init.d]# cd /var/run

[root@s1 run]# rm -rf redis_7001.pid

#杀掉m1主节点，然后删除对应的pid文件

过了一会，查看情况，发现7004已经成为主节点了

切换成master后的102:7004，可以直接读取数据

查看7001的日志情况，显示了7001切换为从节点，并7004成为主节点

再试着把101:7001给重新启动，

发现恢复过来，7001自动作为slave挂载到了102:7004上面去

实验成功！！！

---

三、redis cluster通过master水平扩容来支撑更高的读写吞吐+海量数据

====================================================================================================

redis cluster模式下，不建议做物理的读写分离了

我们建议通过master的水平扩容，来横向扩展读写吞吐量，还有支撑更多的海量数据

redis单机，读吞吐是5w/s，写吞吐2w/s

扩展redis更多master，那么如果有5台master，不就读吞吐可以达到总量25/s QPS，写可以达到10w/s QPS

redis单机，内存，6-8G

如果redis内存过大，那么fork类操作的时候很耗时，会导致请求延时的问题

扩容到5台master，能支撑的总的缓存数据量就是30G，40G -> 100台，600G，800G，甚至1T+，海量数据

1、redis是怎么扩容的，加入新master

---

• 创建需要的文件夹

mkdir -p /var/log/redis

mkdir -p /etc/redis-cluster

mkdir -p /var/redis/7007

• 创建对应7001.conf的配置文件，并放置在/etc/redis/下

port 7007

cluster-enabled yes

cluster-config-file /etc/redis-cluster/node-7007.conf

cluster-node-timeout 15000

daemonize yes

pidfile /var/run/redis_7007.pid

dir /var/redis/7007

logfile /var/log/redis/7007.log

bind 192.168.109.103

appendonly yes

• 创建对应启动脚本redis_7007，放置在/etc/init.d/下

• 手动启动一个新的redis实例，在7007端口上

• 连接到新的redis实例上，cluster nodes，确认自己是否加入了集群，作为了一个新的master

redis-trib.rb add-node 192.168.109.103:7007 192.168.109.101:7001

redis-trib.rb check 192.168.109.101:7001

7007加入成功，但是他是以master主节点加入的，并且没有slots，那他就无法处理数据

2、reshard数据迁移

---

resharding：把一部分hash slot从一些node上迁移到另外一些node上

./redis-trib.rb reshard 192.168.109.101:7001

要把之前3个master上，总共4096个hashslot迁移到新的第四个master上去

16384/4

How many slots do you want to move (from 1 to 16384)?

4096

What is the receiving node ID? #指定要迁移的目标节点node id

1cc3fc38e522b6136832cea140595be390993460

Please enter all the source node IDs.

Type ‘all’ to use all the nodes as source nodes for the hash slots.

Type ‘done’ once you entered all the source nodes IDs.

#指定要迁移的数据源节点node id

Source node #1:c4220974b2bbca56502fea562dd47166af064026

Source node #2:dfd566548ec8e4d1a52773c84c0c3845aa5c9bbf

Source node #3:a74166c80bb4645a0bc71c50c9f36c33e2e0e7fb

Source node #4：done #输入完就done

Do you want to proceed with the proposed reshard plan (yes/no)?

yes

• 再次check检查一下

redis-trib.rb check 192.168.109.101:7001

发现7007已经有对应的4096个hash slots了

3、添加node作为slave

---

增加slave，在rediscluster中是增加高可用性，保证master宕机后还有slave可以被选成master，保持运作

• 在s3虚拟机上再添加一个redis实例，作为上面的7007的slave从节点

• 创建对应文件夹

mkdir -p /var/log/redis

mkdir -p /etc/redis-cluster

mkdir -p /var/redis/7008

• 创建对应7001.conf的配置文件7008.conf，并放置在/etc/redis/下

port 7008

cluster-enabled yes

cluster-config-file /etc/redis-cluster/node-7008.conf

cluster-node-timeout 15000

daemonize yes

pidfile /var/run/redis_7008.pid

dir /var/redis/7008

logfile /var/log/redis/7008.log

bind 192.168.31.227

appendonly yes

• 创建对应7008的启动脚本，在/etc/init.d/下，名为redis_7008

• 启动7008实例

• 将7008实例挂载到7004下面做slave从节点

redis-trib.rb add-node --slave --master-id a74166c80bb4645a0bc71c50c9f36c33e2e0e7fb 192.168.109.103:7008 192.168.109.101:7001

• 检查

redis-trib.rb check 192.168.109.101:7001

4、删除node

---

先用resharding将数据都移除到其他节点，确保node为空之后，才能执行remove操作

现在是4个master，一共16384个hash slots，那么一个master上有4096个hash slots，那么如果要删除一个node，就是16384/4等于4096个hash slots，我们要将这4096平分改不删除的3个master上面，也就是4096/3，那就要2个是1365，1个是1366

• 先做hash slots的迁移，重复上面的步骤，迁移hash slots

./redis-trib.rb reshard 192.168.109.101:7001 #迁移命令

How many slots do you want to move (from 1 to 16384)? 1365

What is the receiving node ID? #另外3个master的nodeid，指定要迁移的目标节点node id

Source node #7007的node id，数据源

• 检查，保证要删除的master节点的hash slots数量为 0

redis-trib.rb check 192.168.109.101:7001

如果你要删除的master节点下面有slave节点，当你清空了一个master的hash slot时，redis cluster就会自动将其slave挂载到其他master上去

写在最后

为了这次面试，也收集了很多的面试题！

以下是部分面试题截图

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

片保存下来直接上传(img-rPl8F5O3-1620031062020)(C:/Users/PePe/AppData/Roaming/Typora/typora-user-images/image-20210503154925016.png)]](https://i-blog.csdnimg.cn/blog_migrate/a5ab12f9317d8d53145488fa997230ac.png)

如果你要删除的master节点下面有slave节点，当你清空了一个master的hash slot时，redis cluster就会自动将其slave挂载到其他master上去

写在最后

为了这次面试，也收集了很多的面试题！

以下是部分面试题截图

[外链图片转存中…(img-ZELS7HUb-1714906674805)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取