Gakkiyomi的博客 👋🏼

你问我爱陈欣欣吗？我爱！但是陈欣欣爱我吗？我不知道，在骗走我50w和我的纯真无邪之后，再次遇到之后，直到她自杀之后，我发现我爱她，一个捞女用命来证明给我看了，她真的爱我。于是我开始复仇，不管是为了陈欣欣还是反捞工作，我都要继续捣毁这个组织。 但是我不理解的是：我能不能放下，即为她报仇之后，我能不能爱别人的问题。 在复仇的路上，我遇见了何月盈。最初她在我眼里只是个冷酷邪恶的敌人。但当我走近她，看到了她坚硬外表下的伤痕——悲惨的童年，以及她硬壳伪装下的自己。她也在我的恋爱技术和性格人品下爱上了我，这时候我爱她吗？我不知道。在要上床的时候我推开了她，是为了陈欣欣吗？我不知道。她真实的自己是一个阳光，开朗，温暖的人，和她的伪装完全相反。最终我还是为了复仇，我严惩了她，错了就是错了。可是在我继续复仇的时候，由于最终boss实力太强，我一次一次的失败，一次一次生命危在旦夕的时候，出来救我的，是何月盈，有时候爱上一个人只是一个瞬间。我能力不足，无法复仇，我可不可以放下？我可不可以爱上何月盈。 所谓《白月光的杀伤力》《欣欣已死，是非对错我已无心分辨》，我只想说人不能永远活在悼念里。我祭奠过死去的爱情，....

36小时通关了steam版本的剑星，总体来说，5分剧情，4分通马桶大世界任务，6分的换皮小怪，8分的战斗手感和爽度还有12分的女主身材展示和100+套的衣服套装。总体是一个8分游戏，游戏嘛能让人感受到荷尔蒙分泌和情绪价值就行。 关于这款游戏，多说无益。请看：

今天是 2025 年 6 月 15 日 农历五月二十，一个普通的日子，也是我的 29 岁生日。 和往年一样，今年收到的生日祝福和礼物，依然只来自父母。 上一次收到朋友的生日祝福，还是在 2015 年，已经是十年前了。那时还没有微信，朋友是在 QQ 空间的留言板上给我发的祝福。 我一直记得，也很感谢她。 其实，我和她一直有联系，虽然只是“微博网友”。看着她分享生活的点点滴滴，那些细碎的片段，像微光一样，偶尔也让我平淡的日子泛起一丝色彩。 也许是受她感染，我也开始学着在微博上表达自己，分享一些日常。这像是一种笨拙的尝试，试着也点亮一点属于自己的光。

上周末早上一起床，打开电脑steam发现匹诺曹的谎言dlc发布了，赶紧买了下载玩，历史两天，大概12个小时全成就通关。 12个小时左右的流程建立在我并没有大规模卡boss的情况下，所有boss的难度基本不大，最终boss我也只打了4次就过了，反而是一些小怪和精英boss很粪，有明显恶心人的成分，比如三狗屠神阵，和血牛精英怪，当然大部分都可以使用游戏内置的道具或者技能来化解，硬莽的确很恶心。数值很高，建议调低难度，能调难度就是人性化，一刀死和三刀死是完全不同的体验。 地图设计延续了本体的优秀水平，美术风格依旧在线。剧情上不剧透了，基本上是讲了本体故事线之前的事也就是回到过去，改变了一些历史进程，遇到了一些如雷贯耳的"传奇"。 但是考虑到这个dlc129元的定价最终我还是给出8分的评价。

已经预购剑星/明末渊虚之羽豪华版 想玩第一狂战士卡赞，有的速来 库里有 黑神话悟空 战神4 师父 艾尔登法环 黑魂1/3 只狼 无限机兵 匹诺曹的谎言 堕落之主 帕斯卡契约 记忆边境 钢之崛起 义闻录轮回 仁王2 2077带往日之影 巫师3 GTA5 大表哥2 对马岛之魂 霍格沃滋之遗 博德之门3 刺客信条起源奥德赛 孤岛惊魂345 小丑牌 土豆兄弟 米塔 三伏 烟火 美末1 黑暗世界因与果 空洞骑士 暗影火炬城 苍翼混沌效应 暖雪 大侠立志传 逸剑风云决 苏丹的游戏 英雄立志传三国志 三国志14PK 文明6 全战三国 双影奇境 湮灭 山河旅探 古墓丽影三部曲 NBA2K全套 希望库存重合度别太高 RPG多的也可以 绿玩别胡整 加家庭库需要在同一ip地址登录账号（不能接受的别来） 满足条件的，评论区报名，贴上steamid

什么是责任链模式 在构建复杂系统时，我们常常面临这样的挑战： 一个请求或事件需要经过多个处理环节 ，这些环节可能动态变化，处理者在运行时才能确定。如何优雅地组织这些处理逻辑，避免代码陷入臃肿的"巨无霸方法"困境？ 想象这样的场景：系统启动初始化流程需要依次执行用户初始化、展示数据加载、元数据配置和系统Banner展示等步骤。如果不用设计模式，代码往往沦为这样的"一坨"： public void initSystem() { // 初始化用户模块 initUserService(); // 加载展示数据 loadDisplayData(); // 配置元数据 configureMetadata(); // 展示系统Banner showStartupBanner(); // 新增需求：添加系统监控 initMonitoring(); // 每次新增都要修改这个核心方法! // 未来可能还要添加更多步骤... } 这种实现存在三大痛点： 违反开闭原则 ：每次新增初始化步骤都要修改initSystem()方法 耦合度高 ：各步骤执行顺序硬编码在单一方法中 ....

端午前一周的凌晨，打开手机发现刚过零点，心想看看《黑神话：悟空》艺术设定展的门票还能抢到吗？居然还有！马上下定了一张5月31号的门票，60块钱，性价比超高。 我是个公共交通与穷游的忠实爱好者。出行住宿靠青旅，交通靠火车，追求的是极致性价比。这本身，也成了旅途中的别样乐趣。 转眼到了5月30号。踏上过夜的快速列车，于31号下午抵达杭州。匆匆办完青旅入住，便跳上公交直奔中国美术学院美术馆。刚抵门口，天就飘起了细密的小雨，只得火急火燎地冲进展馆。进门先煞有介事地“拜”了土地庙，算是入乡随俗。随后从一楼漫游至三楼，熟悉的记忆潮水般涌来——无论是绢布上细腻手绘的《影神图》，橱窗里各个人气角色的精致手办，还是那在射灯下熠熠生辉的纯金金箍。游戏中那些曾并肩作战或奋力对抗的武器与铠甲，此刻化作实物陈列眼前，这感觉真是太棒了。 而真正让心弦被拨动的，是展馆里两幕平凡的光景： 一幕是，一个扎着马尾的女孩，正对着身旁的同伴眉飞色舞，滔滔不绝地拆解着每一处关卡地图的玄机，兴奋地指出地图上关底Boss位置，她在分享的时候眼睛里有光。 另一幕是，一位父亲半蹲着，手指轻点着《影神图》上形态各异的小怪....

菠萝博客v2.6.2版本最有用的功能就是订阅博主，利用博客单点订阅在一个平台集中收集你想看的博文和信息。 此功能目前已上线本人博客 https://gakkiyomi.blog/follows.html 基本实现 订阅关注 查看我的关注 展示博主最新博文列表 查看博文详情 对于严格遵守RSS协议的博文，我们是可以完美适配到我们自己的皮肤中的，但有的博主并没有暴露完整的博文内容，所以这里点击详情之后会链到原博文地址，如：andypan 而如: ruanyifeng 和diygod 则可以完美渲染在博客端。 定时每天拉取一次更新，保证实时性。 想体验的用户可以使用这个版本的镜像： docker pull tangcuyu/bolo-solo:v2.6.2.dev20250524130704 由于个人开发，所以没有精力对所有皮肤进行支持，目前只支持butterfly皮肤，如有兴趣或者嫌弃更新慢也可以提交pr来支持更多你想要的皮肤。 https://github.com/bolo-blog/bolo-solo/pulls

这个书单是我从自己以前读过的或者目前正在读的所有书里精挑细选出来的，里面的书籍都是我个人相对喜欢以及认为有比较有价值的；这份书单会不定期更新，如果有看到符合口味的，欢迎交流！

起因 之前一直在折腾自己的博客，比如博客和摸鱼派互通，自动生成github的个人主页，添加个人简历等一些小功能。于是跟作者 @[链接] 沟通一下决定release一个新版本出来，说干就干。 结果 经过一个多星期辛苦奋斗，Bolo 博客系统迎来了 v2.6.1 的版本。这次更新不仅修复了多个历史遗留问 ....

你们结束每天工作后都会干点什么？摸鱼吗？而我结束工作后，会尝试在公司内网知识空间搜索感兴趣话题的博文来沉淀提升，看着各路高僧大能输出的爆炸好文，总能让我分泌多巴胺，舒服一下午。但今天浏览时发现个熟悉的名字YYY（匿名代替）——这不是我现在开发项目中代码提交量第二的主要维护者吗？虽然没和她做过业务对接，但一直佩服她写的优雅代码。居然是个漂亮的小姐姐！点进主页看到：已退隐江湖... 通过代码提交记录发现，是四月份离的职。 在她主页满满一页的博文列表中，最吸引我眼球的恰恰就是第一篇和最后一篇。首篇讲述了她大学生活和初入职场的成长故事，看着她贴出的油画作品，突然让我联想到计算机领域名著《黑客与画家》——从画画到软件开发看似天差地别，但只要付诸行动就能实现。从百度到托福再到蚂蚁，这段波澜壮阔却又波澜不惊的经历，完美印证了博文标题《一个有故事的女同学》。 而最后一篇博文，则是她的离职感言和总结，看着她在公司1700+天里发生的点点滴滴，从刚入职的不适应到成为团队不可或缺的人物和团宠。看着她每次团建合照中增长的秀发和逐渐脱离稚气的面容，看着她参与开源项目、内部创业、参加创新孵化项目、混入各种大大小小....

2025年了，有人还在用博客吗？苦恼自己的博文评论区没人互动？来试试这款Bolo博客吧。我们怀念黑客派的时光，而正如同从黑客派走向摸鱼派，之前的Solo博客也进化成了Bolo博客。 Bolo博客 Bolo博客是摸鱼派创始人，用爱发电组织创始人 adlered https://fishpi.cn/me ....

今年的五一跟往常不同,往常我都是宅在家里的.今年的五一则不一样,顶着感冒发烧参加了大学同学的婚礼.新郎脱稿真挚的发言和岳母的一番发言和礼物都深深的感动了我. 婚礼现场还抽中了一个礼物,不知为何我们同学这桌有三个中奖,严重怀疑给我们走后门了 看到了最抽象的车牌,敢用这个车牌的人一定是个乐子人 期间顺便和大学同学们游玩了下湘潭的万楼景区,超多的人和超难停的车,感谢🙏问界m7超强的自动泊车 参加完婚礼,我们几个同学一起踏上了去往武功山的高铁,武功山风景没毛病,就是规划不是很好,下山和上山的路太窄,经常拥堵发生矛盾. 这张照片里有我,发现没? 我甚至不知道谁拍的,有时间去问问 当我们爬完山之后等待下山的索道时,大概等了1个多小时,一位朋友轻拍我的肩膀跟我说,你是不是不开心,我当时一愣,跟她说: "没有啊" 其实沉默不代表不开心,只是我有点累了,更多的是排队带来的心情烦躁和腰部疼痛😩 最后坐着回酒店的的士,看着天空下起了暴雨,感叹太幸运了,如果没下来就下雨的话,我不知道该自闭成什么样 最后一张图是山顶一些志愿者或者驴友自发带的签名旗,我也写了我的名字,你们能找到吗?

Faas 架构 在现代云计算的范畴里,FaaS是一个比较新潮的概念,在FaaS里面用户只需要关注自己的代码逻辑,可能是一个函数或者是一个脚本,不用关注底层的资源或者程序运行所需的运行时。也不用关注资源负载和流量并发度和100%免运维体验，因为这些FaaS都帮我们解决了，这通常意味着开发周期更短。 以RAG平台的知识入库场景为例，预处理流程（分片→Embedding→向量存储）存在以下技术挑战： 计算密集型操作导致同步处理吞吐量受限 异构Embedding模型（如未来多模态支持）带来的运行时环境差异 海量任务下的资源弹性需求 通过FaaS架构实现异步任务系统，我们构建了如下解决方案： 事件驱动架构 ：RAG平台将知识录入请求投递至消息队列，解耦前后端处理流程 动态资源分配 ：自定义函数实例配置为2C2G规格，基于队列堆积情况自动扩缩容（Max 100并发） 冷启动优化 ：实例空闲60秒后自动回收，结合Go运行时实现200ms级冷启动延迟，提高资源利用率。 函数运行时 上面说了这么多，只是为了介绍FaaS这种云计算架构的一些试用场景和优点。那么什么是函数运行时？ 函数运行时，顾名思....

[图片] 18小时通关了3月27号上线的国产类魂游戏无限机兵。充满了如碎片化叙事，多支线影响结局，特色的跳跳乐等类魂游戏特色。steam特别好评。 https://store.steampowered.com/app/2407270/AI_LIMIT/ 如果你是一个魂游享受者，这个游戏你绝对不应该错 ....

上周通关了三伏，由神作《烟火》的制作人月光蟑螂新推出的悬疑解谜游戏。如果《烟火》是10分的话，《三伏》也就7-8分的游戏。 [图片] https://store.steampowered.com/app/1880330/_/ 整体给我的感受依旧还是延续了烟火的20世纪初的美术风格，充满了生活气息和民 ....

在经过26个小时的闯荡和随着我手中的骨钉刺穿了苍白容器的躯壳。这场与自身命运对抗的仪式，为我的圣巢之旅画上了阶段性句点。当通关结局1之后跳出的80%的完成度意味着仍有其他内容并未探索完全，这种未竟感反而成为最好的二周目邀请函。 我作为第一次接触银河恶魔城类型的游戏，这款Team Cherry打造的虫 ....

2024 —— 我可能是我这辈子最爽的一年 一月份 由于职业调整，我开启流浪中国计划，也是受了各大up主的影响 [图片] 一次说走就走的旅行，是给自己的奖励，毕竟工作5年没有旅游过。 香港 元朗抽象艺术 去香港没有玩什么 ，walk了一下，吃了一个叉烧肠粉，感觉一般，主要是去香港ariport飞北京 ....

KIP-500 在Kafka2.8之前，Kafka一直使用Zookeeper1来存储和管理Partition3和Broker4的元数据。以及选举一个Broker作为Kafka控制器 Kafka与Zookeeper5 Kafka移除Zookeeper1的动机 提高元数据管理的鲁棒性和可扩展性 支持更多分区 减少部署和配置难度 架构 当前，一个 Kafka 集群包含多个 broker 节点和一个外部的 ZooKeeper 仲裁节点。我们在这个图中描绘了 4 个 broker 节点和 3 个 ZooKeeper 节点，这是一个小型集群的典型规模。Kafka控制器（用橙色表示）在选举后从 ZooKeeper 仲裁节点加载其状态。控制器向其他 broker 节点推送更新，例如 LeaderAndIsr 和 UpdateMetadata 消息。 请注意，这个图有些误导。除了控制器，其他 broker 也会与 ZooKeeper 通信。因此，实际上应该从每个 broker 到 ZK 画线。然而，画这么多线会使图表难以阅读。另一个问题是，这个图省略了外部命令行工具和实用程序可以在没有控制器参....

简介 Raft 算法实际上是 Multi-Paxos的一个变种，通过新增两个约束： 追加日志约束 ：Raft 中追加节点的日志必须是串行连续的，而 Multi-Paxos 中则可以并发追加日志（实际上 Multi-Paxos 的并发也只是针对日志追加，最后应用到内部 State Machine 的时候还是必须保证顺序）。 选主的限制：Raft 中只有那些拥有最新、最全日志的节点才能当选 Leader 节点，而 Multi-Paxos 由于允许并发写日志，因此无法确定一个拥有最新、最全日志的节点，因此可以选择任意一个节点作为 Leader，但是选主之后必须要把 Leader 节点的日志补全。 基于这两个限制，Raft 算法的实现比 Multi-Paxos 更加简单易懂，不过由于 Multi-Paxos 的并发度更高，因此从理论上来说 Multi-Paxos 的性能会更好一些，但是到现在为止业界也没有一份权威的测试报告来支撑这一观点。 对比一下 Multi-Paxos 和 Raft 下集群中可能存在的日志顺序： 可以看出，Raft 中永远满足这样一个约束：follower log 一.......