【无标题】

目录

Redis的zset底层数据实现原理：

Redis分片集群如何实现：

QPS并发100、500、1000、1000+后框架如何设计及拆分：

数据过亿后数据库表如何进行拆分？

java 系统部署后,如何有效利用服务器的性能

---

spring cloud eureka 缓存底层响应时间如何实现？
redis的zset底层数据实现原理？
redis分片集群如何实现的？
QPS 并发100，500，1000，1000+后框架如何设计及拆分？
数据过亿后数据库表如何进行拆分？
系统部署后，如何有效利用服务器的性能？
介绍一下当前系统流程？如何进行子模块域的拆分？

如何保证接口及系统性能达到t99的级别？

Spring Cloud Eureka缓存底层响应时间实现：

Spring Cloud Eureka使用了ConcurrentHashMap作为缓存，它是一种线程安全的哈希表，可以在多线程环境下安全地进行访问。当Eureka客户端向Eureka服务器请求注册或者获取服务列表时，Eureka服务器会先在缓存中查找是否存在相应的数据，如果存在则直接返回给客户端，否则会从数据库中查询数据，并将查询结果缓存到ConcurrentHashMap中，下次请求时就可以直接返回缓存中的数据，避免了频繁的数据库访问，从而提高了响应速度。

Redis的zset底层数据实现原理：

Redis的zset底层数据结构是跳表（Skip List），它是一种有序的链表，可以在O(log n)的时间复杂度内进行插入、删除、查找等操作。跳表通过在每个节点上增加多个指针，从而实现了快速地查找目标节点的功能。

Redis分片集群如何实现：

Redis分片集群可以通过使用Redis Cluster来实现。Redis Cluster是Redis官方提供的分布式集群方案，它将数据分成多个片段，每个节点只存储部分数据，从而实现了数据的水平扩展。Redis Cluster采用了主从复制的方式来实现高可用性，每个主节点都会有若干个从节点，当主节点宕机时，会自动将其中一个从节点升级为主节点。

QPS并发100、500、1000、1000+后框架如何设计及拆分：

 

在QPS并发量逐步增大的情况下，可以采取如下的框架设计和拆分策略：
水平扩展：通过增加服务器数量来增加系统的处理能力。
缓存优化：使用缓存技术来减轻数据库的负载压力。
异步处理：将一些复杂、耗时的操作异步化，从而不影响主线程的处理能力。
分布式部署：将系统拆分成多个子系统，每个子系统独立部署，从而降低系统的复杂度，提高可伸缩性。
数据库分片：将数据按照某种规则划分成多个片段，存储在不同的数据库节点上，从而实现水平扩展。

数据过亿后数据库表如何进行拆分？
 

当数据库出现了读写性能瓶颈的时候，我们优先使用一些比较常规的优化手段来进行解决。例如比较常见的有：增加索引、优化索引、读写分离、增加从库等方式。

如果使用这些常规的手段也无法解决的时候啊，我们才会去考虑用分库分表来进行解决。

在使用分库分表的时候，必须充分考虑业务未来的整体发展。至少做到这次分库分表之后，未来的三到五年内不需要再进行分库分表。

分库分表

当前主要的拆分方式有两种：水平拆分和垂直拆分。

java 系统部署后,如何有效利用服务器的性能

高并发读，缓存+静态化，尽量少用数据库； 高并发写，nio，多线程+队列

使用缓存减少数据库压力，使用消息队列削峰

dubbo底层架构

 

1.首先服务提供者会启动服务，然后将服务注册到服务注册中心。
2.服务消费者会定时拉取服务提供者列表。
3.当服务消费者需要调用服务提供者接口的时候，因为他不能直接远程调用提供者的接口，所以需要生成一个动态代理对象，然后通过这个代理对象去调用远程接口。
4.生成代理对象之后，会走到Cluster层，这里会获取服务提供者列表的数据，感知到目前所能调用的服务提供者有哪些。
5.然后Cluster会根据指定的算法，做负载均衡，选出要调用的服务提供者。
6.选择好服务提供者之后，再选择指定的协议格式。
7.Exchange会根据指定的协议格式，进行请求数据封装，封装成request请求。
8.请求封装好之后，就会通过网络通信框架将请求发送出去。
9.服务提供者那边同样会有网络通信框架，他会监听指定的端口号，当接收到请求之后，会将请求进行反序列化。
10.反序列化之后，再根据Exchange根据指定协议格式将请求解析出来。
11.然后再通过动态代理对象调用服务提供者的对应接口。
 

zookeeper 宕机，dubbo还能用吗？

zookeeper 宕机，消费者可以调用提供者服务，因为有本地缓存。

没有注册中心，也可以调服务，可以使用 dubbo 直连的方式。

zk故障新选主的过程

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。leader选举是保证分布式数据一致性的关键。
 

Leader：主要是负责数据的写入，如果超过半数同意，那么就广播进行写入；
Follower：主要负责查询请求并将写入请求发送给leader，参与选举和写入投票；
Observe：也是负责查询请求并将写入请求发送给leader，不参加投票，只被动接收结果

zxid:即zookeeper事务id号

（1）初始阶段，都会给自己投票。
（2）当接收到来自其他服务器的投票时，都需要将别人的投票和自己的投票进行pk，规则如下：
优先检查zxid。zxid比较大的服务器优先作为leader。
如果zxid相同的话，就比较sid，sid比较大的服务器作为leader。

 

zookeeper数据恢复过程

threadlocal为啥内存泄露

kafka