issue 关联 Environment Server: Java-server, dubbo version v3.0.14 Client: Dubbo-go, v3.1.1 Protocol: Dubbo Registry: Nacos, v2.1.2 Problem dubbo-go 的 client 端无法调用 dubbo 的 server 端的代码。 问题分析 在调试并复现代码问题后，我发现问题出在 QueryDataSource 方法中： 1 QueryDataSource func(ctx context.Context, id int) (*DataSource, error) dubbo:"queryDataSource" 根本原因是类型不匹配：在 Go 中，int 和 int64 通常都是 8 字节，而在 Java 中，int 类型只有 4 字节。 这种差异导致 Java 无法正确识别要调用的方法。 解决方案： 将 Go 方法中的 int 参数更改为 int32。 1 QueryDataSource func(ctx context.Context, id int32) (*DataSource, error) dubbo:"queryDataSource" 这个修改应该能解决类型兼容性问题。 Go 中的枚举表示 我注意到您定义的 Java 枚举类型在 Go 中表示为字符串： 1 Type string hessian:"type" // Mapped from Java enum 为了解决这个问题并确保在 Go 中正确处理枚举，我建议使用 dubbo-go-hessian2 仓库中提供的枚举生成工具。 ...

issue 关联 先查出可以清理的数据 按索引删除数据 给delete加上limit 查询代码后发现，在 tcc-fence 模式下并不存在自动删除日志的功能，于是准备实现该功能。 pull request 1. 配置文件 在 config 模块中新增了 Config 结构体，用于配置 TCC Fence 日志清理功能的相关参数。 1 2 3 4 5 6 type Config struct { Enable bool `yaml:"enable" json:"enable" koanf:"enable"` Url string `yaml:"url" json:"url" koanf:"url"` LogTableName string `yaml:"log-table-name" json:"log-table-name" koanf:"log-table-name"` CleanPeriod time.Duration `yaml:"clean-period" json:"clean-period" koanf:"clean-period"` } Enable: 是否启用日志清理功能。 Url: 数据库连接字符串。 LogTableName: TCC 日志表的名称。 CleanPeriod: 清理任务的执行周期。 2. 初始化函数 在客户端的 InitTCC 函数中添加了对 fence 的初始化逻辑。 ...

issue 关联 client: dubbo-go: v3.2.0-rc2 server: dubbo v3.3.0 registry: zookeeper 问题 1：biStream 客户端没有关闭长连接的接口；如果服务端不调用 onCompleted，那么 Receive 会永久 block 客户端应当具有主动 Close 能力才对，底层使用的是 grpc，而 grpc 客户端是能够主动关闭连接的。 问题 2：Java 服务端调用 onCompleted() 后，biStream.Receive 返回 EOF 但是和服务端的 TCP 连接仍然存在；我知道 dubbo client 内部是连接池，但是我测试了一下，TCP 连接似乎并没有被复用 源码分析 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 func TestBiDiStream2(svc greet.GreetService) error { fmt.Printf("start to test triple bidi stream 2\n") stream, err := svc.GreetStream(context.Background()) if err != nil { return err } if sendErr := stream.Send(&greet.GreetStreamRequest{Name: "stream client!"}); sendErr != nil { return err } resp, err := stream.Recv() if err != nil { return err } fmt.Printf("triple bidi stream2 resp: %s\n", resp.Greeting) if err := stream.CloseRequest(); err != nil { return err } if err := stream.CloseResponse(); err != nil { return err } fmt.Printf("========>TestBiDiStream end, close stream...\n") return nil } 在其中 ...

1. 引言（Introduction） 我们意识到，我们的大部分计算都涉及对输入中的每个逻辑 “记录” 应用 map 操作，以便计算一组中间键 / 值对，然后将 reduce 操作应用于共享同一键的所有值，以便适当地组合派生数据。我们使用具有用户指定 map 和 reduce 操作的函数模型，使我们能够轻松地并行化大型计算，并使用重新执行作为容错的主要机制。 这项工作的主要贡献是一个简单的和强大的接口，可实现自动并行化和大规模计算的分布，结合起来使用此接口的实现大型商用PC集群上的高性能。 2. 编程模型（Programming Model） Map 和 Reduce 的定义与功能 Map（映射）：是由用户编写的函数，它接受一个输入键值对，然后对输入数据进行处理，产生一组中间键值对。例如在单词计数的例子中，Map 函数会读取文档内容（值），将文档中的每个单词作为键，“1” 作为值，输出一系列 < 单词，“1”> 这样的中间键值对，表示每个单词出现了一次。其作用是将大规模数据的处理分解为对每个独立数据块（逻辑 “记录”）的操作，为后续的合并处理提供基础数据。 Reduce（归约）：同样由用户编写，它接受一个中间键以及与该键相关联的一组值。Reduce 函数的主要任务是将具有相同键的值进行合并处理，通常是将这些值进行某种计算（如求和、连接等），最终生成可能更小的一组值，一般每个 Reduce 调用产生零个或一个输出值。以单词计数为例，Reduce 函数会接收一个单词（键）和该单词对应的所有计数（值的列表），然后将这些计数相加，得到该单词的总出现次数，输出 <单词，总次数> 这样的键值对。Reduce 操作实现了对中间数据的合并和聚合，从而得到最终想要的结果形式。 Map 和 Reduce 函数共同构成了 MapReduce 编程模型的核心，通过这种分而治之的方式，能够在大规模集群上高效地处理海量数据。 典型使用案例（如单词计数） 大型文档集合中每个单词的出现次数的问题 1 2 3 4 5 6 7 8 9 10 11 12 13 // key: document name // value: document contents map(String key, String value): for each word w in value: EmitIntermediate(w, "1"); // key: a word // values: a list of counts 迭代器，用于遍历与该单词相关联的所有计数 reduce(String key, Iterator values): int result = 0; for each v in values: result += ParseInt(v); Emit(AsString(result)); map: 遍历文档内容中的每个单词w。对于每个单词，使用EmitIntermediate(w, "1")发出一个中间键值对，其中键是单词w，值是字符串"1"。这表示该单词在当前文档中出现了一次（以简单的计数为 1 来表示每次出现）。 ...

总体纲领 在coding之前 我们需要先有个draft(草案) 包含 背景 约束条件 设计的目的与折中 存在的问题以及改进这四个部分 背景 目标： 精准复现、定位并理解技术问题的本质、影响范围及业务上下文。 关键活动： 问题复现与场景描述 (Reproduce & Describe): 复现路径： 明确稳定复现问题的具体步骤、输入和环境（开发、测试、生产环境；特定用户/数据）。 异常表现： 清晰描述“不符合预期”的具体行为，包括错误日志、监控指标异常（延迟、错误率、资源使用率）、UI/API 表现等。 预期行为： 明确在同样场景下，系统 应该 表现出什么样的行为。 根因分析 (Root Cause Analysis - RCA): 信息收集： 收集相关日志、Metrics、Traces、Dump 文件、配置信息、代码版本、变更历史。 关联分析： 分析时间线，将问题现象与系统变更、流量波动、依赖服务异常等进行关联。 假设与验证： 提出可能的根因假设，并通过调试、日志分析、实验等手段进行验证或排除。 影响评估 (Impact Assessment): 业务影响： 评估问题对用户、业务流程、收入、SLA/SLO 的具体影响。 技术影响： 评估问题对系统其他模块、数据一致性、安全性的潜在影响。 现状审视 (Review Current State): 审视当前代码库、架构设计、技术文档中与问题相关部分。 了解是否存在已知的类似问题或临时的 Workaround。 产出： 一份详尽的 技术问题分析报告 (Technical Problem Report / RCA Report)，包含复现步骤、根本原因、影响范围和相关证据。 约束条件 目标： 明确解决方案必须遵守的技术边界和需要达成的技术/业务指标。 关键活动： 识别技术约束 (Identify Technical Constraints): 平台/语言/框架： 必须使用的编程语言、框架、操作系统、云平台等。 架构/兼容性： 必须兼容的现有系统架构、API 接口、数据格式、老版本等。 资源限制： CPU、内存、存储、网络带宽、预算等硬性限制。 规范/安全： 必须遵守的编码规范、安全标准、合规要求。 定义技术目标 (Define Technical Goals): 功能性目标： 解决方案需要实现的核心功能。 非功能性目标 (NFRs): 明确性能（延迟、QPS）、可用性 (Availability)、可靠性 (Reliability)、可伸缩性 (Scalability)、可维护性 (Maintainability)、可测试性 (Testability) 等方面的具体指标要求。 明确核心假设 (Identify Technical Assumptions): 方案设计所依赖的底层库行为、第三方服务承诺、网络环境稳定性等假设。 产出： 一份 技术规格与约束清单 (Technical Specifications & Constraints List)，作为设计方案的输入和评判标准。 ...