spring +redis +kafka+zookeeper讲解

最新推荐文章于 2025-11-23 15:45:13 发布

原创最新推荐文章于 2025-11-23 15:45:13 发布 · 713 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#spring +redis +kafka+zookeepe

spring +redis +kafka+zookeepe 专栏收录该内容

1 篇文章

订阅专栏

本文探讨了代理设计模式的概念，包括静态代理和动态代理，以及它们在AOP中的应用。深入解析了Spring框架的核心机制，如IoC、DI、BeanFactory与ApplicationContext的区别，bean的实例化方式，以及配置文件的灵活性。同时，文章详细介绍了Redis的持久化策略，包括RDB和AOF的优缺点，以及数据备份和容灾策略。

代理是一种常用的设计模式，其目的就是为其他对象提供一个代理以控制对某个对象的访问。代理类负责为
委托类预处理消息，过滤消息并转发消息，以及进行消息被委托类执行后的后续处理。
静态代理：由程序员创建代理类或特定工具自动生成源代码再对其编译。在程序运行前代理类的.class文件就已经存在了。
动态代理：在程序运行时运用反射机制动态创建而成。
AOP(面向切面编程)的基本原理：
比如日志系统、事务、拦截器、权限控制等。这也就是。

动态代理与静态代理相比较，最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法中处理（InvocationHandler.invoke）。
这样，在接口方法数量比较多的时候，我们可以进行灵活处理，而不需要像静态代理那样每一个方法进行中转。而且动态代理的应用使我们的类职责更加单一，复用性更强

面试题： IoC 和 DI的区别？
IoC 控制反转，指将对象的创建权，反转到Spring容器， DI 依赖注入，指Spring创建对象的过程中，将对象依赖属性通过配置进行注入
BeanFactory 接口和 ApplicationContext 接口有什么区别？
①ApplicationContext 接口继承BeanFactory接口，Spring核心工厂是BeanFactory ,BeanFactory采取延迟加载，第一次getBean时才会初始化Bean, ApplicationContext
是会在加载配置文件时初始化Bean。
②ApplicationContext是对BeanFactory扩展，它可以进行国际化处理、事件传递和bean自动装配以及各种不同应用层的Context实现

spring配置bean实例化有哪些方式？
1）使用类构造器实例化(默认无参数) 2）使用静态工厂方法实例化(简单工厂模式) 3）使用实例工厂方法实例化(工厂方法模式)
8.Spring的核心类有哪些，各有什么作用？
BeanFactory：产生一个新的实例，可以实现单例模式
BeanWrapper：提供统一的get及set方法
ApplicationContext:提供框架的实现，包括BeanFactory的所有功能
Spring里面applicationContext.xml文件能不能改成其他文件名？
你的web应用启动的时候初始化。缺省情况下，它会在WEB-INF/applicationContext.xml文件找Spring的配置。你可以通过定义一个<context-param>元素名字为”
contextConfigLocation”来改变Spring配置文件的位置
Bean注入属性有哪几种方式？
spring支持构造器注入和setter方法注入构造器注入，通过 <constructor-arg> 元素完成注入
setter方法注入，通过<property> 元素完成注入【开发中常用方式】

redis:
Save：save 时只管保存，其他不管，全部阻塞。
Bgsave：redis 会在后台进行快照操作，快照操作的同时还可以响应客户端的请求，可以通过 lastsave 命令获取最后一次成功执行快照的时间。
如何恢复：将备份文件(dump.rdb)移动到 redis 安装目录并启动服务即可 Config get dir 命令可获取目录
如何停止：动态停止 RDB 保存规则的方法：redis -cli config set save “”
Rdb:在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的 snapshot 快照，它恢复时就是将快照文件直接读到内存里。
Redis 会单独的创建(fork) 一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化还的文件。整个过程总，主进程是不进行任何 IO 操作，这就确保了极高的性能，如果需要进行大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。
Fork 的作用是复制一个与当前进程一样的进程，新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
隐患：若当前的进程的数据量庞大，那么 fork 之后数据量*2,此时就会造成服务器压力大，运行性能降低

Rewrite：AOF 采用文件追加方式，文件会越来越来大为避免出现此种情况，新增了重写机制，aof 文件的大小超过所设定的阈值时，redis 就会自动 aof 文件的内容压缩，值保留可以恢复数据的最小指令集，可以使用命令 bgrewirteaof。
重写原理：aof 文件持续增长而大时，会 fork 出一条新进程来将文件重写(也就
是先写临时文件最后再 rename)，遍历新进程的内存中的数据，每条记录有一条 set 语句，重写 aof 文件的操作，并没有读取旧的的 aof 文件，而是将整个内存的数据库内容用命令的方式重写了一个新的 aof 文件，这点和快照有点类似。
触发机制：redis 会记录上次重写的 aof 的大小，默认的配置当 aof 文件大小上次 rewrite 后大小的一倍且文件大于 64M 触发(3G)
no-appendfsync-on-rewrite no : 重写时是否可以运用 Appendfsync 用默认 no 即可，保证数据安全
auto-aof-rewrite-percentage 倍数设置基准值
auto-aof-rewrite-min-size 设置基准值大小

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。
而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，
对文件进行分析（parse）也很轻松。导出（export） AOF 文件也非常简单：举个例子，如果你不小心执行了 FLUSHALL 命令，
但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis ，就可以将数据集恢复到 FLUSHALL 执行之前的状态。
备份Redis 数据：
磁盘故障，节点失效
Redis 对于数据备份是非常友好的，因为你可以在服务器运行的时候对 RDB 文件进行复制： RDB 文件一旦被创建，就不会进行任何修改。当服务器要创建一个新的 RDB 文件时，它先将文件的内容保存在一个临时文件里面，当临时文件写入完毕时，程序才使用 rename(2) 原子地用临时文件替换原来的 RDB 文件。
这也就是说，无论何时，复制 RDB 文件都是绝对安全的。
建议：
创建一个定期任务（cron job），每小时将一个 RDB 文件备份到一个文件夹，并且每天将一个 RDB 文件备份到另一个文件夹。
确保快照的备份都带有相应的日期和时间信息，每次执行定期任务脚本时，使用 find 命令来删除过期的快照：比如说，你可以保留最近 48 小时内的每小时快照，还可以保留最近一两个月的每日快照。
至少每天一次，将 RDB 备份到你的数据中心之外，或者至少是备份到你运行 Redis 服务器的物理机器之外。
容灾备份：Redis 的容灾备份基本上就是对数据进行备份，并将这些备份传送到多个不同的外部数据中心。

从服务器配置
配置一个从服务器非常简单，只要在配置文件中增加以下的这一行就可以了：
slaveof 192.168.1.1 6379
另外一种方法是调用 SLAVEOF 命令，输入主服务器的 IP 和端口，然后同步就会开始
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK
只读从服务器
从 Redis 2.6 开始，从服务器支持只读模式，并且该模式为从服务器的默认模式。
只读模式由 redis.conf 文件中的 slave-read-only 选项控制，也可以通过 CONFIG SET 命令来开启或关闭这个模式。
只读从服务器会拒绝执行任何写命令，所以不会出现因为操作失误而将数据不小心写入到了从服务器的情况。
另外，对一个从属服务器执行命令 SLAVEOF NO ONE 将使得这个从属服务器关闭复制功能，并从从属服务器转变回主服务器，原来同步所得的数据集不会被丢弃。
从服务器相关配置：

如果主服务器通过 requirepass 选项设置了密码，那么为了让从服务器的同步操作可以顺利进行，我们也必须为从服务器进行相应的身份验证设置。
对于一个正在运行的服务器，可以使用客户端输入以下命令：
config set masterauth
要永久地设置这个密码，那么可以将它加入到配置文件中：
masterauth

主服务器只在有至少 N 个从服务器的情况下，才执行写操作
从 Redis 2.8 开始，为了保证数据的安全性，可以通过配置，让主服务器只在有至少 N 个当前已连接从服务器的情况下，才执行写命令。
不过，因为 Redis 使用异步复制，所以主服务器发送的写数据并不一定会被从服务器接收到，因此，数据丢失的可能性仍然是存在的。
以下是这个特性的运作原理：

从服务器以每秒一次的频率 PING 主服务器一次，并报告复制流的处理情况。
主服务器会记录各个从服务器最后一次向它发送 PING 的时间。
用户可以通过配置，指定网络延迟的最大值 min-slaves-max-lag ，以及执行写操作所需的至少从服务器数量 min-slaves-to-write 。
如果至少有 min-slaves-to-write 个从服务器，并且这些服务器的延迟值都少于 min-slaves-max-lag 秒，那么主服务器就会执行客户端请求的写操作。
另一方面，如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件，那么写操作就不会被执行，主服务器会向请求执行写操作的客户端返回一个错误。
以下是这个特性的两个选项和它们所需的参数：
min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>
<id> <ip:port> <flags> <master> <ping-sent> <pong-recv> <config-epoch> <link-state> <slot> <slot> ... <slot>
id: 节点ID,是一个40字节的随机字符串，这个值在节点启动的时候创建，并且永远不会改变（除非使用CLUSTER RESET HARD命令）。
ip:port: 客户端与节点通信使用的地址.
flags: 逗号分割的标记位，可能的值有: myself, master, slave, fail?, fail, handshake, noaddr, noflags. 下一部分将详细介绍这些标记.
master: 如果节点是slave，并且已知master节点，则这里列出master节点ID,否则的话这里列出”-“。
ping-sent: 最近一次发送ping的时间，这个时间是一个unix毫秒时间戳，0代表没有发送过.
pong-recv: 最近一次收到pong的时间，使用unix时间戳表示.
config-epoch: 节点的epoch值（or of the current master if the node is a slave）。每当节点发生失败切换时，都会创建一个新的，独特的，递增的epoch。如果多个节点竞争同一个哈希槽时，epoch值更高的节点会抢夺到。
link-state: node-to-node集群总线使用的链接的状态，我们使用这个链接与集群中其他节点进行通信.值可以是 connected 和 disconnected.
slot: 哈希槽值或者一个哈希槽范围. 从第9个参数开始，后面最多可能有16384个数(limit never reached)。代表当前节点可以提供服务的所有哈希槽值。如果只是一个值,那就是只有一个槽会被使用。如果是一个范围，这个值表示为起始槽-结束槽，节点将处理包括起始槽和结束槽在内的所有哈希槽。
各flags的含义 (上面所说数据项3):

myself: 当前连接的节点.
master: 节点是master.
slave: 节点是slave.
fail?: 节点处于PFAIL 状态。当前节点无法联系，但逻辑上是可达的 (非 FAIL 状态).
fail: 节点处于FAIL 状态. 大部分节点都无法与其取得联系将会将改节点由 PFAIL 状态升级至FAIL状态。
handshake: 还未取得信任的节点，当前正在与其进行握手.
noaddr: 没有地址的节点（No address known for this node）.
noflags: 连个标记都没有（No flags at all）

cluster info:
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:2
cluster_stats_messages_sent:1483972
cluster_stats_messages_received:1483968
cluster_state: ok状态表示集群可以正常接受查询请求。fail 状态表示，至少有一个哈希槽没有被绑定（说明有哈希槽没有被绑定到任意一个节点），或者在错误的状态（节点可以提供服务但是带有FAIL 标记），或者该节点无法联系到多数master节点。.
cluster_slots_assigned: 已分配到集群节点的哈希槽数量（不是没有被绑定的数量）。16384个哈希槽全部被分配到集群节点是集群正常运行的必要条件.
cluster_slots_ok: 哈希槽状态不是FAIL 和 PFAIL 的数量.
cluster_slots_pfail: 哈希槽状态是 PFAIL的数量。只要哈希槽状态没有被升级到FAIL状态，这些哈希槽仍然可以被正常处理。PFAIL状态表示我们当前不能和节点进行交互，但这种状态只是临时的错误状态。
cluster_slots_fail: 哈希槽状态是FAIL的数量。如果值不是0，那么集群节点将无法提供查询服务，除非cluster-require-full-coverage被设置为no .
cluster_known_nodes: 集群中节点数量，包括处于握手状态还没有成为集群正式成员的节点.
cluster_size: 至少包含一个哈希槽且能够提供服务的master节点数量.
cluster_current_epoch: 集群本地Current Epoch变量的值。这个值在节点故障转移过程时有用，它总是递增和唯一的。
cluster_my_epoch: 当前正在使用的节点的Config Epoch值. 这个是关联在本节点的版本值.
cluster_stats_messages_sent: 通过node-to-node二进制总线发送的消息数量.
cluster_stats_messages_received: 通过node-to-node二进制总线接收的消息数量.
zookeeper 在kafka中的作用是什么？
1. broker在zk中注册
kafka的每个broker（相当于一个节点，相当于一个机器）在启动时，都会在zk中注册，告诉zk其brokerid，在整个的集群中，broker.id/brokers/ids，当节点失效时，zk就会删除该节点，就很方便的监控整个集群broker的变化，及时调整负载均衡。