Ivorysillegal's Blog

在偶然的学习中接触到了近期炙手可热的MCP 于是在学习之后草率写一点自己的体会 笔者对AI学习了解主要停留在应用方面 这里也主要MCP在这上的作用和修改 When it comes to MCP 的概念，个人认为从AI工具的使用现状、其的作用和能带来的改善作为角度切入会更好理解. 那么 MCP是什么生态协同 AI与MCP（?）从21年的gpt3.5开始 ai技术不断进步 各种各样的效果评测 也能实打实得说明其无论是在计算 编码 搜索等领域上都有了很大的进步 但是相比之下 其本身集成速度（AI+）应用发展的很慢 3.5时代 我们的使用方法停留在文字对话 语句文字补全 仅chat对话和completion两模式 在以CloseAI为主的（那时还是Open的）独角兽厂商的推动下 人们通过他们提供的api 初步实现了多载体上使用api ide上 chrome插件上 在ds-r1横空出世之后 也是在国内掀起了一模一样的热潮 然后为了想让ai更好的完成任务 人们通过prompt 预训练 rag等方法 尝试通过加强某部分知识在ai“心目中的地位” 事实证明也确实起到了很好的效果...

Thread why need it 希望计算机在同一时间可以执行多个任务 将代码以更加优雅的方式组织 解耦 减少运行的复杂度 并行运算 利用现代计算机多核CPU的硬件优势 一个线程 = 一个串行执行代码的单元 他本身自己是有状态的（PCB） 含有： PC 程序计数器 存储变量（寄存器） Stack 程序当前的执行点 与PC不同 pc是记录运行的位置 stack则是记录当前程序的执行点（具体的执行信息） 而多线程的并行运行策略 第一个策略为多核处理器上所使用的每个CPU都运行一个线程，即线程数=CPU数 这种情况下如果只有4个CPU，却有上千个线程。就完蛋了 所以主流是为 一个CPU在多个线程之间来回切换 即俗称的线程上下文切换 大多数操作系统会在结合两种策略使用 首先会运行在所有可用的CPU核上 其次会在CPU核会不断切换当前运行的进程 因为通常来说，线程数会远远多于CPU的核数。 在主流的操作系统中 允许在一个用户进程中包括多个线程 并且该类线程会共享当前进程的地址空间 XV6中不支持...

Lecture 10 有一段时间没看了 忘了好多 锁 why need it 多个CPU核的并行计算可以带来倍数级的提升 但是假如一个程序运行在多个核上 会同时带来一些竞态的问题 并且需要内核能够正确的处理它们 有很多老生常谈的环境 例如说什么生产者消费者模式 共享内存的情景下 我们都需要使用锁来保证多个核之间 数据的一致性 简而言之 多核并行计算带来了效率提升 也带来了多核时的并发控制成本 和编码难度 实际的情况有些令人失望，因为我们想要通过并行来获得高性能，我们想要并行的在不同的CPU核上执行系统调用，但是如果这些系统调用使用了共享的数据，我们又需要使用锁，而锁又会使得这些系统调用串行执行，所以最后锁反过来又限制了性能。 那么除了使用锁还有其他的方法可以提高性能吗 肯定是有的 但是之前的技术发展路线已经解释了 为什么锁的使用频率会越来越高 text 从这图可以看到 从2000年开始： CPU时钟频率就没有再增加过了（绿） 意味着...

这条记录一些乱七八糟好玩的 我是Java大王

欢迎来到我的博客！ Make Progamming (Backend ×) Great Again! 这里主要是学习笔记 总得输出点什么 量化一下自己 除此之外 有一些碎碎念 有一些纪念 主播成分很杂 谁能想到听rage的opium小子喜欢看魔女之旅呢 谁能想到喜欢浴血黑帮的哥们在刷aerichandesu呢 谁能想到玩女神异闻录的雨宫莲的最爱是LFA呢 🤟 下方Aplayer是小飞机 无法解析所以从flac压缩成了MMP3 need any, contact me!

Introuduction在分布式系统的日常维护当中 有很多数据在概念上说非常清晰明了的 例如说是爬虫所获得的数据 日志 活跃指标等等 但是这些数据往往非常大 正因此这些数据往往也是分布式在多台机器上存储的 当服务请求到来的时候 为了加快请求的速度和效率 往往会进行一个多台机器上并行查询计算的优化 此时 原本清晰明了的查询逻辑 却因为数据量和服务机器的规模而变得冗杂 而MapReduce正是在这样的分布式场景下的一个答复 他是一个全新的抽象 囊括了并行计算中会出现的并行化、容错、数据分发、负载均衡等一系列问题 为分布式系统下的kv查询计算 提供一套简易而强大的使用接口 也由于他的应用方向是分布式下的场景，所以相比单机场景下，其所做的某些处理可能显得比较冗余。这时候需要考虑并发对这一操作所会带来的影响。 这里所提到的只是一种抽象的设计方法，但是具体的实现还是需要根据具体的业务逻辑进行设计的 Programming...

why 首先 为什么需要有这个链路追踪系统？ 首先先从业务的角度来进行思考 某些业务情境下 例如说是消息下发 支付 或者等等 当我们需要在发起执行业务的请求后 需要获取业务的执行情况、执行进度的时候 可以通过这个链路追踪系统中的信息获取 然后也是最主流的使用情景 —— 在运维、开发、测试的时候 假如某个程序报了始料未及的错误 由于是微服务情境下 多台机器的使用会导致很难纠错 而这个分布式链路追踪系统则可以很直观的告诉开发者 是哪里报了错 快速的定位错误 定性错误 这样的轮子现在已经有很多了 这里所体现的是在具体场景下的一些优化 首先就是 在应用体量很大 数据量很多的时候 这时候应该怎么进行处理 这时候会带来很多问题 首先就是数据量大 想要查询日志的话 本身的耗时成本 查询时所带来的CPU成本 假如是业务功能的话 这个查询的频率会更高 所带来的劣势也会更大 还有一个最显而易见的存储成本的问题 不同的云存储成本 如何优化呢？ 首先一种方式就是 流处理 + 批处理 利用Spark或者是Flink等组件 还有一种思路 也就是这里所主要进行的优化是 摒弃完全的中心化存储...

写于来上海的第二个周末 本想找个地逛逛的 睡太晚 + 起太晚导致泡汤 想了一下还是找个地记录一下 来了之后 去逛过什么地方 有什么感想 充当日记 喜欢一些乱七八糟的citywalk 瞎走不打卡乱拍一气只发原图版 2025.3.9 延安西路 - 新华路 - 上海影城 - 幸福里 - 小路唱片 - 南京路步行街 洋房好看 对于两广做题家 跟广州骑楼比起来别有一番气质 2025.3.16 两个周末都把公司mac带回家了 起初是为了能在mac上下些常用软件 想着把这套环境都搬上服务器上 但是说实话。。。 对于2核2G的服务器还是有点沉重的 有点懒有点怕烦 最后只把博客一套的搬上云了 （之前都是在WSL上写了编译的） 然后还有xv6的乱七八糟 但是qemu啥的编译链就没搞了 （实在是太过沉重。。。 编译效率也会慢） 凑巧发现mac的外放很爽 然后才想起来 mac有四个大喇叭也是直接飞上云端 于是这个星期就带回来放了两天歌。。。 凑巧周五早下班 又凑巧周五Playboi Carti居然发了 I AM MUSIC 那就不得不外放启动了 👄 说起来 这专初听略显疲态 不做其他评价...

通过指定query 为其构造生成选择题的评测集prompt 让他生成对应的选择题选项 并且标注上选项的错误原因以及正确答案 通过prompt将大模型输出的内容再度美化成为json格式 将这个json格式的数据做一定的清晰后进行乱序 提取其中问题选项 与原query结合 构造出一道完整的选择题 调用大模型尝试写这道题 同理流程 得到最终答案

透明多级分流系统如何解释这个名字？ 原有的架构或者单体系统无法支撑需求的负载 于是在他的基础上进行进一步改造 通过引入不同部分的中间层 将程序的运行链路分割解耦 对每一部分依据需求进行优化或拓展 据此所生成的多个层次 此为“多级” 多个分布式中间件平衡的承担压力 此为“分流” 对进行的优化应当是用户无感知的 不会对原有的操作逻辑和用户体验带来任何的影响 此为“透明” 三个名词就组成了设计时的最基本要求 而具体如何体现的 原文通过客户端缓存、域名服务器、传输链路、内容分发网络、负载均衡器、服务端缓存接下来进行介绍 但是还有一个更基本的要求就是 所谓的因架构设计所引入的各个中间件 也需要尤其所存在的意义。 原文称之为 不是每一个系统都要追求高并发、高可用的，根据系统的用户量、峰值流量和团队本身的技术与运维能力来考虑如何部署这些设施才是合理的做法，在能满足需求的前提下，最简单的系统就是最好的系统。 一个经典的例子就是StackOverFlow 全世界主流的程序员交流平台 其设计所谓很多的分布式组件 只有简简单单的10台mysql机器就足以...