Ivorysillegal's Blog

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

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

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机器就足以...

RPC“为了让计算机像调用本地方法一样调用远程方法” 这是RPC最原始的定义，于是可以从调用本地方法的思路上来分析RPC 调用的时候 需要知道入参 方法 返回结果 本质上和RPC上是一样的 即 发什么 发给谁 得到什么的问题 原文中采用了这样的例子 12345678910// Caller : 调用者，代码里的main()// Callee ： 被调用者，代码里的println()// Call Site ： 调用点，即发生方法调用的指令流位置// Parameter ： 参数，由Caller传递给Callee的数据，即“hello world”// Retval ： 返回值，由Callee传递给Caller的数据。以下代码中如果方法能够正常结束，它是void，如果方法异常完成，它是对应的异常public static void main(String[] args) { System.out.println(“hello world”);} 如上是一个调用时的minimal的情景 通讯在实际的RPC中 还需要考虑如 怎么发 什么形式发...

...

测试用例如何设计写在一面反思后 目前的测试思维还是太差了 想要思考出一套适合自己的方法论 当我们拿到一个场景题 想要来设计一个具体场景的测试用例的时候 我应该怎么去思考？ 将不同情景下的需求都抽象出来 根据产品实现的多个方面进行抽象 有什么方面？功能 性能 安全 UI 兼容性 功能功能首先就是 对于该场景下的这一部分 他是否完成所需要实现的功能 这里我将他归类为普遍功能和特殊功能 通过产品本身的性质进行定义 所谓的普遍功能 本质上就是说 同类型的其他产品都会实现的一些功能 以及他们都会接触到的一些测试用例 例如说搜索框和大模型QA中的输入相关 例如说购物车和售货机 他是否可以跳转支付 所谓的特殊功能就是在这一个场景下的具体差异实现 例如说搜索框的搜索跳转与大模型QA中的文本生成回复 购物车的网购和售货机的货物弹出 以及针对拆分出的各个模块 分别测试他的所对应边界值（异常处理） 以及处理措施 该两者也是这一部分的一大组成 性能然后就可以从性能这方面进行思考 性能本身是很难量化的 所以我们可以借助一些数据来体现他 同样可以从两个方面进行体现 一个是正常服务状态下的...