面试题：自定义Redis事件调度负载均衡策略

设计思路

节点性能评估：定期（例如每5分钟）收集各Redis节点的硬件性能指标，如CPU使用率、内存使用率、网络带宽等，将这些指标综合加权计算得出每个节点的性能得分，性能越好得分越高。
读写操作分类：区分读操作和写操作，由于业务对实时性要求高，写操作优先保证数据一致性和实时性，读操作则更注重快速响应。
负载均衡策略：
- 写操作：优先分配到性能较好且当前负载较低的节点，以确保数据能快速持久化且不影响其他操作。这里的负载可以通过当前节点正在处理的任务数来衡量。
- 读操作：根据节点性能得分和当前负载，按比例分配读请求，性能越好且负载越低的节点分配到的读请求比例越高，这样可以充分利用高性能节点的处理能力，同时兼顾低性能节点，避免低性能节点因请求过多而响应过慢。

性能数据采集模块：编写脚本或利用现有工具（如Prometheus + Grafana）定时采集Redis各节点的硬件性能指标，将数据存储在一个集中的数据库（如InfluxDB）中。
负载监测模块：通过Redis的INFO命令实时获取每个节点当前正在处理的任务数，作为负载指标。
调度器：
- 读取性能数据和负载数据，计算每个节点的性能得分和负载情况。
- 对于写请求，按照性能得分从高到低、负载从低到高的顺序选择节点进行分配。
- 对于读请求，根据节点性能得分和负载情况计算每个节点应分配的请求比例，然后按照比例随机分配读请求到各个节点。可以使用加权随机算法来实现，例如给每个节点分配与其请求比例对应的权重，然后根据权重随机选择节点。
动态调整：随着节点性能和负载的变化，调度器实时更新节点的性能得分和负载情况，动态调整请求分配策略。

响应时间指标：通过在客户端记录每个读写请求从发送到接收到响应的时间，计算平均响应时间、95%响应时间等指标。如果平均响应时间和95%响应时间都能满足业务对实时性的要求，说明策略有效。可以使用工具如JMeter来模拟大量请求并收集响应时间数据。
吞吐量指标：统计单位时间内系统能够处理的读写请求数量，观察吞吐量是否随着节点数量的增加而线性增长。如果吞吐量没有因为节点性能差异而出现明显瓶颈，说明策略能较好地利用各节点资源。可以在调度器中添加计数器来统计请求数量，并结合时间窗口计算吞吐量。
节点负载均衡度：检查各节点的CPU使用率、内存使用率、任务处理数等负载指标是否分布均匀。可以通过监控工具（如Grafana）绘制各节点负载指标的图表，直观查看负载均衡情况。如果各节点负载差异在可接受范围内，说明策略有效地均衡了负载。
数据一致性：对于写操作，确保数据在各个节点之间的一致性。可以通过定期进行数据校验（例如使用Redis的Sentinel机制进行数据同步检查），如果没有出现数据不一致的情况，说明写操作的分配策略保证了数据一致性，进而证明策略的有效性。