- 博客(240)
- 收藏
- 关注
RSS订阅原创 【Netty系列】自定义协议
这个注释版本应该能帮助更好地理解Netty的工作机制和自定义协议的处理流程。实际开发中还需要添加超时处理、心跳机制等增强健壮性。
2025-06-01 10:30:00
301
原创 【Netty系列】自定义协议 vs HTTP协议
每个请求/响应需携带Header（约200-800字节）每次请求需TCP + SSL握手（如需HTTPS）利用Range头实现断点续传，浏览器直接支持。队头阻塞（HOL Blocking）仅需必要元数据（如4字节长度字段）1-5ms/消息（根据消息复杂度）直接读取长度字段 + 内容字节流。兼容性强，工具链成熟，便于调试。文本格式（JSON/XML）多路复用（Stream并行）高（文本解析、字符串处理）节省带宽，适合资源受限设备。二进制格式（紧凑无冗余）0.1-0.5ms/消息。低（二进制直接操作）
2025-06-01 10:30:00
726
原创 【Netty系列】实现HTTP协议
可根据具体业务需求扩展处理逻辑（如添加路由、参数解析、Session管理等）。聚合请求（HttpObjectAggregator）聚合响应（HttpObjectAggregator）解码响应（HttpResponseDecoder）编码响应（HttpResponseEncoder）解码请求（HttpRequestDecoder）编码请求（HttpRequestEncoder）
2025-05-31 15:33:01
462
原创 【Netty系列】消息编码解码框架
在网络通信中，消息的编码（序列化）和解码（反序列化）是核心环节，直接影响通信性能和开发效率。建议根据具体场景组合使用，例如：Netty + Protobuf 构建高性能网关，Kafka + Avro 实现流数据处理。人性化格式，适合配置文件。结构严谨，验证能力强。
2025-05-31 15:29:46
1026
原创 【Netty系列】Protobuf编码解码：客户端、服务端实现
这个示例完整展示了Netty与Protobuf的整合，实现了二进制数据的高效传输。实际生产环境中可根据需要添加心跳机制、重连策略等扩展功能。
2025-05-31 15:29:04
272
原创 【Netty系列】解决TCP粘包和拆包：LengthFieldBasedFrameDecoder
运行示例后，你将在控制台看到完整的请求-响应日志，验证粘包问题的解决效果。通过这种方式，Netty 会自动根据长度字段切分完整的数据包，长度字段值后的内容长度调整（若长度字段包含自身长度，需调整）长度字段占用的字节数（例如4字节表示int）解析后跳过的字节数（例如跳过长度字段本身）解决 TCP 粘包/拆包问题的。允许的最大帧长度（防止内存溢出）长度字段的起始偏移量（通常为0）
2025-05-31 11:19:45
447
原创 【Netty系列】TCP协议：粘包和拆包
问题是网络编程中常见的技术挑战，尤其是在基于流的传输协议（如TCP）中。通过合理设计协议，结合Netty的解码器，能高效解决粘包/拆包问题，确保数据的完整性和正确性。TCP协议传输数据时的。
2025-05-31 11:04:50
474
原创 【Netty系列】Reactor 模式 1
在示例中，主 Reactor 处理连接，子 Reactor 处理 I/O，多个客户端请求被高效分发到不同线程，最终由。：将网络连接的建立（Accept）与 I/O 读写（Read/Write）分离到不同的线程处理，避免单线程阻塞。下面通过一个服务端处理多请求的例子，详细解释 Reactor 模式在 Netty 中的实现。Reactor 模式是 Netty 高性能的核心设计思想之一，它通过。在 Netty 中，Reactor 模式的实现体现为。Reactor 模式的核心是。高（单线程处理多连接）
2025-05-30 17:20:30
1262
原创 【Netty系列】Netty 框架介绍
Netty是一个基于 Java NIO（Non-blocking I/O）的异步事件驱动网络应用框架，旨在快速开发高性能、高可靠性的网络服务器和客户端。它简化了 TCP/UDP 等协议的编程，并提供了高度可定制的组件，适用于高并发场景（如游戏服务器、即时通讯、分布式系统等）。
2025-05-28 08:53:03
1052
原创 【Netty系列】Netty vs Java NIO
虽然 Netty 底层基于 Java NIO，但它在编程模型、线程管理、内存优化和协议支持等方面做了大量增强。内置 HTTP、WebSocket、Protobuf 等编解码器。需依赖第三方库（如 Mina、Grizzly）丰富的官方和社区插件（如日志、SSL 支持）需自行实现（如循环读取、缓冲区拼接）开发者需自行设计线程池和事件循环。需从零实现（如 HTTP 解析）无内置支持，需自行实现对象池。（读写指针分离，无需翻转）需手动分配连接给不同线程。需手动注册事件和监听。线程池，自动绑定连接。
2025-05-28 08:47:39
360
原创 【Mytais系列】SqlSession
是 MyBatis 的核心交互接口，负责 SQL 执行、事务管理和缓存控制。正确使用它的生命周期和事务机制，能有效提升数据库操作的安全性和性能。结合 Mapper 接口和 Spring 等框架的事务管理（如。是框架的核心接口之一，它是应用程序与 MyBatis 交互的。，用于执行 SQL 命令、管理事务和访问数据库。查询单条记录，参数为 SQL 标识和参数对象。获取 Mapper 接口的动态代理对象。内的多次相同查询会命中缓存。），可以进一步简化开发流程。清空当前会话的一级缓存。级别（会话级缓存）。
2025-05-03 16:22:13
1142
原创 【Mytais系列】Myatis的设计模式
掌握这些模式的应用场景，能显著提升代码的可维护性和架构的灵活性。SqlSessionFactory 创建对象。复杂 DTO 构建、HTTP 请求参数封装。构建 Configuration 对象。ErrorContext 管理错误信息。不同 Executor 实现选择。RPC 客户端、AOP 切面。Executor 执行流程。算法切换（排序、支付方式）IO 流增强（缓冲、加密）数据库连接池、日志工厂。Mapper 接口实现。统一流程（支付、导出）过滤器链（权限、日志）全局配置、线程池管理。
2025-05-03 16:04:56
754
原创 【Mytais系列】Type模块：源码
实现了灵活的类型映射机制。其源码设计注重扩展性（支持自定义处理器）、性能（高效的类型查找）和线程安全（并发容器与无状态对象），是 MyBatis 框架中处理数据类型的核心基础设施。理解其源码实现，有助于开发者更好地定制类型转换逻辑，解决复杂场景下的 ORM 问题。（类型系统）是框架实现 Java 类型与数据库类型映射的核心模块，其源码设计精巧且高度可扩展。：定义 Java 类型与 JDBC 类型之间的转换逻辑。：管理类型别名，简化 XML 配置中的类名书写。类型，存储为逗号分隔的字符串。
2025-05-03 16:03:50
890
原创 【Mytais系列】Type模块：类型转换
等机制，屏蔽了 Java 对象与数据库类型之间的差异，使开发者能够专注于业务逻辑。等机制，实现了数据库字段与 Java 对象属性的无缝转换。是框架处理 Java 类型与数据库类型之间映射的核心模块，它通过。创建结果集映射的 Java 对象实例（如 POJO、集合等）。为 Java 类型定义别名，简化 XML 配置中的类型名称。处理 Java 类型与 JDBC 类型之间的转换（如。，可以高效处理复杂数据类型，提升代码可维护性和灵活性。MyBatis 的类型系统通过。，管理类型与处理器的映射关系。
2025-05-03 16:01:46
612
原创 【Mytais系列】Datasource模块：数据源连接
模块是 SQL 执行的基础设施，通过高效管理数据库连接的生命周期和池化策略，显著提升系统性能。合理配置数据源类型及参数，结合第三方连接池的高级功能，可确保高并发场景下的稳定性和可扩展性。模块是框架与数据库交互的核心基础设施，负责管理数据库连接的创建、分配、释放及池化，直接影响 SQL 执行效率和资源利用率。（MyBatis 自带）、第三方池（HikariCP、Druid 等）。无可用连接时的等待时间（毫秒，默认 20000）。控制连接的获取、释放、超时检测、有效性校验等。最大活跃连接数（默认 10）。
2025-05-03 16:00:30
1108
原创 【Mytais系列】Update语句执行流程
理解这一流程可帮助开发者合理设计事务边界和缓存策略，避免因缓存未及时清理导致的数据不一致问题。绑定 SQL 参数（支持复杂对象和动态参数）。用户操作入口，封装会话状态和事务控制。执行器，负责缓存清理和 SQL 执行（详细描述的 MyBatis 执行。处理 SQL 语句（创建。管理事务提交/回滚（如。处理二级缓存逻辑）。MyBatis 执行。
2025-05-03 15:58:18
892
原创 【Mytais系列】Select语句执行流程
和缓存更新机制，有助于优化数据访问层设计，平衡性能与数据一致性。的优先级策略，最大化利用缓存提升性能。理解其内部组件协作（如。用户操作 MyBatis 的入口，封装了会话状态和数据库操作。执行器，负责缓存查询和 SQL 执行（分为。详细描述的 MyBatis 执行一条。处理结果集（映射为 Java 对象）。装饰器模式实现，添加二级缓存逻辑。处理 SQL 语句（创建。绑定 SQL 参数。实际执行数据库操作。
2025-05-03 15:56:50
482
原创 【Mytais系列】缓存机制：一级缓存、二级缓存
MyBatis 的缓存机制是其性能优化的重要特性，分为和，两者在作用范围、生命周期和使用场景上有显著差异。
2025-05-03 15:21:50
703
原创 【Mytais系列】核心工作流程
通过这个流程设计，MyBatis 在保持灵活性的同时，提供了比原生 JDBC 更高效、更易维护的数据库操作方案。将 ResultSet 转换为 Java 对象（通过 ResultMap 和 TypeHandler）拦截接口方法调用，将方法名映射为 SQL 语句的唯一ID（namespace.id）将 Java 对象转换为 JDBC 参数（使用 TypeHandler）处理二级缓存（若开启），返回结果给调用方。提交/回滚事务（非自动提交时），关闭资源。SqlSession 内。），管理一级缓存和事务。
2025-05-03 15:19:53
834
原创 【kafka系列】At Most Once语义
通过合理配置，At-Most-Once可为特定场景提供高效、简洁的数据传输能力。若Broker未成功接收消息（如宕机），生产者不会重试，消息直接丢失。执行前崩溃，由于Offset已自动提交，消息不会被重新处理。若消费者拉取消息后，在。
2025-02-15 15:21:01
588
原创 【kafka系列】At Least Once语义
通过合理配置和业务设计，At-Least-Once可平衡可靠性与性能，是大多数场景的推荐选择。若Broker写入成功但网络超时，生产者重试会导致消息重复发送到Topic。失败（如消费者崩溃），下次启动时会重新拉取并处理同一消息，导致积分重复增加。复杂（需生产者、Broker、消费者协同）允许重复的业务（如日志采集）高（事务与协调开销）
2025-02-15 15:11:02
902
原创 【kafka系列】Exactly Once语义
即使在生产者重试、Broker故障或消费者重启等场景下，也能避免数据重复或丢失。正确配置后，Kafka可支持金融支付、实时对账等对数据一致性要求极高的场景。
2025-02-15 14:58:31
696
原创 【kafka系列】Kafka事务的实现原理
正确配置后，Kafka事务可支持金融级场景的精确一次（Exactly-Once）语义。实现跨分区的原子性写入，确保消息要么全部提交，要么全部丢弃。Kafka事务机制通过。
2025-02-15 14:40:28
1556
原创 【kafka系列】Kafka如何实现高吞吐量？
目录1. 生产者端优化核心机制：关键参数：2. Broker端优化核心机制：关键源码逻辑：3. 消费者端优化核心机制：关键参数：全链路优化流程吞吐量瓶颈与调优总结Kafka的高吞吐能力源于其生产者批量压缩、Broker顺序I/O与零拷贝、消费者并行拉取等多层次优化。以下是具体实现机制：2. Broker端优化核心机制： 顺序磁盘I/O： 每个Partition的日志文件（）仅追加写入（Append-Only），顺序写速度可达600MB/s（远高于随机写）。
2025-02-15 14:25:02
1157
原创 【kafka系列】Kafka如何保证消息不丢失？
目录1. 生产者端：确保消息成功发送到Broker核心机制：关键步骤：2. Broker端：持久化与副本同步核心机制：关键源码逻辑：3. 消费者端：可靠消费与Offset提交核心机制：关键步骤：4. 全链路保障流程消息丢失的典型场景与规避总结Kafka通过生产者端确认机制、Broker端持久化与副本同步、消费者端可靠消费三个核心环节保障消息不丢失。以下是具体实现机制与步骤：2. Broker端：持久化与副本同步核心机制： 副本机制（Replication）： 每个Part
2025-02-15 14:11:26
1562
原创 【kafka系列】日志存储设计 & 消息写入、读取
Kafka的日志存储是其高吞吐、持久化能力的核心设计，其结构包含三部分。orders-0LogLogSegmentKafka消息以**批次（RecordBatch）**为单位存储，每个批次包含多条消息，减少I/O开销。EpochSequence（源码见。
2025-02-15 12:55:16
1273
原创 【kafka系列】消费者重平衡 Rebalance
消费者组重平衡是 Kafka 中动态调整分区分配的关键机制，确保消费者组内成员变动或 Topic 分区变化时，负载均衡和消费进度的一致性。组内其他消费者需接管其分区，重平衡期间消息处理暂停（通常几秒到几十秒）。分区重新分配，原有消费者释放部分分区，新消费者开始消费，期间短暂停顿。在 Kafka 消费者组重平衡（Rebalance）过程中，，直到新的分区分配完成。消费者需分配新分区，重平衡期间暂停消费。频繁停顿会导致消息积压，需优化参数（如。
2025-02-15 12:00:59
1350
原创 【kafka系列】消费者
单次拉取的最小数据量（Broker 等待足够数据后返回，提升吞吐量）。消费者与 Broker 的心跳超时时间，超时触发重平衡。空闲连接超时时间（Broker 主动关闭超时连接）。消费者组 ID（同一组内的消费者共享分区负载）。单次拉取的最大数据量（需小于 Broker 的。无初始 Offset 时的策略：<br>-消费者等待 Broker 响应的超时时间。调用的最大间隔时间，超时触发重平衡。自动提交 Offset 的时间间隔（Value 的反序列化类（同上）。返回的最大消息数（避免内存溢出）。
2025-02-15 11:58:44
988
原创 【kafka系列】生产者
以下是 Kafka 生产者（Producer）在日常开发中的。消息在缓冲区等待时间（毫秒），增大可提升吞吐量（但增加延迟）。生产者缓冲区满或元数据不可用时的阻塞时间（超时抛异常）。：等待所有 ISR 副本确认（最高可靠性）。生产者等待 Broker 响应的超时时间。单个批次的大小阈值，达到阈值后立即发送。SSL 证书路径（客户端认证时需配置）。：等待 Leader 确认（默认）。Value 的序列化类（同上）。：不等待确认（可能丢失数据）。发送失败后的重试次数（建议设为。接口），用于监控或修改消息。
2025-02-15 11:56:06
1004
原创 【kafka系列】架构、核心概念
设计目标是高吞吐量、低延迟、可水平扩展，主要用于处理实时数据流。以下是 Kafka 的核心架构和关键概念，帮助你快速理解和使用它。通过动手部署集群、编写生产/消费代码，结合官方文档逐步深入，你可以在实际项目中熟练使用 Kafka！Kafka 的核心优势在于其。
2025-02-09 12:34:32
1296
原创 【kafka系列】Topic 与 Partition
是数据组织的核心概念，它们的映射关系及在 Broker 上的分布直接影响 Kafka 的性能、扩展性和容错能力。假设一个 Kafka 集群有 3 个 Broker（Broker 0、1、2），创建一个 Topic。
2025-02-09 12:19:38
1221
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人