Blog

产生背景1LLM 生成完整回答通常需要一定时间，如果等所有 token 都生成完再返回，用户会感觉首包响应慢、等待时间长。 流式传输特点1234567891011模型每生成一部分 token，就可以立即推送给客户端，客户端可以边接收边展示，无需等待完整回答全部生成。优点： 1. 降低用户感知延迟； 2. 提升交互体验，类似 ChatGPT 逐字输出； 3. 适合长文本生成、代码生成、报告生成等耗

解决的问题：123451.将组件的连接封装起来，对外只提供接口方法调用，具体实现用代理封装，调用变简单2.自动处理Prompt模板，使用@SystemMessage @UserMessage注解、{{}}占位符来拼装完整的Prompt3.可配置自动管理聊天记忆4.自动处理Tool的调用5.自动处理返回的结构化 基础用法:1.一个接口：123456publi

作用1实现rc和rr的隔离级别 1. 一致性视图1.1 组成部分12341.creator_trx_id 创建当前ReadView的事务id2.m_ids 创建视图时的活跃事务id集合 -- 活跃事务：还未提交的事务3.min_trx_id 最小活跃事务id -- m_ids中的最小者4.max_trx_id 创建ReadView时，最大事务id+1 1.2 数据版本可见性判定12345678

两阶段提交流程1231.redolog标记为预提交状态2.binlog写入3.redolog标记为commit 解决的问题前置知识12在innodb引擎中存在redolog，用于提供mysql崩溃恢复的能力（crash-safe）server层中存在binlog，用于数据恢复、主从复制 需要做到1保证crash-safe后的数据和binlog恢复的数据一致 如果不存在两阶段时12341.if

引入依赖12345678910<dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j</artifactId> <version>1.12.2</version></dependency>