分布式系统中的一致性算法和问题解决

分布式系统中的一致性算法和问题解决在撰写脑裂问题相关的博客时发现脑裂问题的产生原因在不同算法下的分布式系统各不相同,需要先大致了解一致性算法并针对性的解决 市面上有很多开源的分布式系统,他们的数据一致性算法不尽相同,例如k-v系统的祖师爷——zookeeper采用的是ZAB的算法,而最近流行的Consul是raft算法,不同数据中心server沟通的方式则是gossip协议 不同的协议和方式对选举和数据同步有不同的处理机制,利用这篇文章来对比常见的分布式一致性算法 一个系统可能会使用多个不同的一致性算法,以便于在不同的业务环节上有着各自更贴切的处理 ps:有种观点是一致性算法不是很准确,因为replica也能保证数据某种程度上具有一致性,有人称之为共识算法
分布式系统中的一致性算法和问题解决2021-03-13鱼鱼

用 AI 写代码越久,我越怕自己“手生”

用 AI 写代码越久,我越怕自己“手生”先说一个可能很多人都有过的瞬间:公司网络抽风,或者 AI 插件突然登录失效,你对着一个空白文件准备写点东西,然后发现自己卡住了 不是不会写,是那种“这个方法的参数顺序是啥来着”“这个异常该在哪一层处理来着”的卡顿 以前这些东西是肌肉记忆,现在得想一想 我第一次意识到这件事的时候,心里咯噔了一下 倒不是怕失业,那个话题太大了,轮不到我在这儿焦虑 我怕的是更具体的东西:当 AI 给出的代码出了问题,我还看不看得出来 这篇文章不打算劝谁少用 AI 我自己每天都在用,而且用得挺开心 我只是想把这种“手生”的感觉拆开看看,它到底是错觉还是真的,以及我目前摸索出来的一些应对办法 说是办法,其实也就是一些习惯,不一定对,供参考
用 AI 写代码越久,我越怕自己“手生”2026-10-08鱼鱼

给 Agent 设计工具:参数与错误返回怎么约定才好用

给 Agent 设计工具:参数与错误返回怎么约定才好用做 Agent 久了会发现:模型“聪不聪明”常常不是瓶颈,工具好不好用才是 同一个模型,换一套清晰的工具契约,成功率能差一截;换一套含糊的,它就会在重试里空转,或者把半成功当成成功继续往下跑 我踩过的坑大多长这样:工具返回一句 "failed",模型不知道是参数错了、权限不够,还是下游超时;于是它换个说法再调一次,参数其实没变 或者工具抛了未捕获异常,框架把它变成空字符串,模型以为“没结果”就去编造 这篇文章只谈两件事:参数怎么设计,以及错误怎么返回,让工具对模型可观测、对系统可重试 图片来源:原创示意图 能用枚举就别用字符串 比如 priority: "high"|"normal"|"low",不要 priority: string 然后在文档里写“建议传 high”
给 Agent 设计工具:参数与错误返回怎么约定才好用2026-10-10鱼鱼

MySQL tips

MySQL tips一些日常接触到的MySQL优化tips,比较散乱 假设有一个用户表,对于一句很简单的查询语句: 假设name与age字段均有单列索引,容易想到的是,MySQL应该会分别走两次索引,并将其结合起来,EXPLAIN也是如此,大多数时候MySQL会进行优化,我们可能会看到EXPLAIN的结果中有Using union或Using soft union,这是MySQL针对OR做了隐性的优化,但当SQL复杂或数据极端情况下,这一语句极容易变成全表扫描,偶尔使用联合索引可能解决问题,更多情况则是MySQL“昏了头”,即使OR条件均涉及数据条数不多,依旧没能在查询语句中使用索引,此时应调整为UNION语句(可以权衡一下重复及顺序是否有影响,可以使用更快的UNION ALL):
MySQL tips2021-01-13鱼鱼

AI大模型定价对比

AI大模型定价对比https://open.bigmodel.cn/pricing 火山方舟也提供端点(GLM3 0.001) https://openai.com/ja-JP/api/pricing/ 出入价格不一样 官网和火山都有 另外有免费版本的
AI大模型定价对比2024-12-18鱼鱼

让 AI 重构老代码,我宁可它一次只动一小步

让 AI 重构老代码,我宁可它一次只动一小步我手上有个老项目,里面有一个结算相关的 Service 类,六百多行 最长的一个方法两百多行,if-else 套了五六层,中间还夹着几段被注释掉、但没人敢删的代码 每次需求要动它,大家都绕着走,能加个分支就加个分支 有一天我终于下决心收拾它 那时候我已经用 AI 写了不少代码,心想重构这种“体力活”,交给它正合适 结果第一次尝试,差点让我对“用 AI 重构”这件事彻底失去信心 后来换了一种做法,才算顺利做完 这篇就讲讲这两次的区别 我把整个类贴给 AI,说:“这个类太乱了,帮我重构得清晰一点,保持功能不变 ” 它给我的结果,单看确实漂亮:长方法拆成了十几个小方法,几种结算方式抽成了策略类,变量名全换成了更有意义的名字
让 AI 重构老代码,我宁可它一次只动一小步2026-10-11鱼鱼

基于Consul的服务注册与发现

基于Consul的服务注册与发现注:文章基于Consul1.6.0版本,部分版本可能会有误差 本文中项目集成部分采用Java语言 consul官网,服务注册/发现是微服务架构中不可或缺的重要组件,起初服务都是单节点的甚至是单体服务,不保障高可用性,也不考虑服务的压力承载,服务之间调用单纯的通过接口访问(HttpClient/RestTemplate),直到后面出现了多个节点的分布式架构,起初的解决手段是在服务端负载均衡,同时在网关层收束接口,使不同的请求转发到对应不同端口上,这也是前后分离防止前端跨域的手段之一: 图中的B服务也可以是多节点,注册在nginx上面的 要命的是,nginx并不具有服务健康检查的功能,服务调用方在调用一个服务之前是无法知悉服务是否可用的,不考虑这一点分布式的架构高可用的目标就成了一个摆设,解决手段也很简单:对超时或是状态码异常的请求进行重试尝试,请求会被分发到其他可用节点,或者采用服务注册与发现机制察觉健康的服务
基于Consul的服务注册与发现2020-01-10鱼鱼

浅析RPC框架Thrift

浅析RPC框架ThriftThrift是由Facebook开发的 RPC远程调用的框架,使用独有的Thrift协议进行可跨语言的远程调用 有点类似protobuf 无论使用何种语言,首先要准备Thrift编译环境,可以去官网下载相应的Thrift执行文件,下文均以Windows为例 下载后可以选择性的配置环境变量,最终在shell中可执行Thrift 在项目中,预先准备好libthrift依赖,maven写法: 例如: 定义一个testService.thrift(idl文件名不重要),一般都会定义在resources的thrift文件夹下: 这里定义了两个方法,分别返回字符串和int类型,在thrift的idl中,对于变量的定义如下:
浅析RPC框架Thrift2022-03-04鱼鱼

安全框架的使用:Shiro

安全框架的使用:ShiroShiro与Sping Security均是java的安全框架,主要用于处理用户身份验证和授权 常见场景为用户系统登录 Shiro易用性强,提供了认证,授权,加密,和会话管理功能 Shiro的三大核心组件 : Subject:即当前用户概念,不止代表着某用户,也可以是进程或任何可能的事物 SecurityManager:即所有Subject的管理者,可以把他看做是一个Shiro框架的全局管理组件,用于调度各种Shiro框架的服务 作用类似于SpringMVC中的DispatcherServlet,用于拦截所有请求并进行处理 Realm:Realm是用户的信息认证器和用户的权限认证器,我们需要自己来实现Realm来自定义的管理我们自己系统内部的权限规则
安全框架的使用:Shiro2019-09-29鱼鱼

MCP 协议入门:给 Agent 一个统一的“工具接口”

MCP 协议入门:给 Agent 一个统一的“工具接口”当 Agent 需要接入越来越多的外部能力——文件系统、数据库、GitHub、内部系统——每个工具都要自己写一套适配代码,非常繁琐 MCP(Model Context Protocol,模型上下文协议) 就是为了解决这个问题而提出的开放协议,由 Anthropic 发布,目标是让“AI 应用”和“外部工具/数据源”之间有一套统一的对接标准 本文从动机出发,讲清楚 MCP 的角色、能力、消息流程,带你用 SDK 写一个最小 Server,再用不依赖 SDK 的方式手写一遍协议交互来理解本质,最后总结安全注意事项、常见坑和 FAQ 从 N×M 到 N+M:Host、Client 与 Server 的分工
MCP 协议入门:给 Agent 一个统一的“工具接口”2026-10-08鱼鱼

RAG 在 Coding Agent 里:什么时候有用,什么时候添乱

RAG 在 Coding Agent 里:什么时候有用,什么时候添乱一提到让 Agent “懂我们的代码库”,很多人的第一反应是上 RAG:把仓库切块、嵌入、丢进向量库,提问时先检索再生成 听起来理所当然,我自己也做过 用下来的感受是:RAG 在 coding agent 里不是默认答案,而是一种有代价的缓存与索引策略 用对了能省上下文、提高命中;用错了会检索到似是而非的片段,把模型带进沟里 这篇文章想尽量说人话:哪些场景我愿意上 RAG,哪些场景我宁愿用“直接读文件 / 搜符号 / 开测试”的工具,以及怎么判断它在添乱 图片来源:原创示意图 Coding Agent 跟“企业内部知识问答”不一样 它通常已经有这些能力: 它缺的往往不是“百科”,而是:在正确的时刻拿到正确的那一小段代码,并且知道这段代码是否仍然有效
RAG 在 Coding Agent 里:什么时候有用,什么时候添乱2026-10-10鱼鱼

AI 生成测试我怎么取舍:哪些让它写,哪些必须人写

AI 生成测试我怎么取舍:哪些让它写,哪些必须人写用 AI 写业务代码越来越顺手之后,下一件很自然的事就是:让它把测试也补上 说实话,这一步的爽感很强——几分钟冒出一堆 should_xxx,覆盖率数字往上跳,CI 绿灯 问题也正好出在这里:绿灯不等于有保险 我经历过一次挺丢脸的事 AI 帮我补了十几个单测,覆盖率从 40% 拉到 75%,合并后第三天生产就炸了 回头看测试,几乎每个都在验证“mock 对象有没有按我设定的方式被调用”,真正的业务不变量一个都没钉住 测试在保护 mock,不在保护系统 这篇文章想说清楚三件事:哪些测例我愿意交给 AI;哪些我坚持人手写;以及怎么减少“假绿” 图片来源:原创示意图 我不想装清高
AI 生成测试我怎么取舍:哪些让它写,哪些必须人写2026-10-10鱼鱼
网站地图
1
首页 博客 {{screen}} 第 {{page}} 页
博客索引
{{blog.createDate}} ◔ {{blog.timeline}} 小头像 {{blog.author}} {{tag}}
{{blog.likeCount}}{{blog.commentCount}}
分类下暂时没有文章哦!
主题分类
{{taggroup.label}} 

{{tag.value}}