本来只是想把 《1Q84》的读后感写下,现在觉得还是把这篇当成我今年的读书总结吧,不过先从《1Q84》说起。
严格来讲,这不是很书面化的读后感,可能我想写的也只是像聊天一样的说下我读过的书,包括的技术博客其实也是类似的,以后或许会转变,但是目前水平如此吧,写多了可能会变好,也可能不会。
开始正文吧,这书有点类似于海边的卡夫卡,一开始是通过两条故事线,穿插着叙述,一条是青豆的,不算是个职业杀手的女杀手,要去解决一个经常家暴的斯文败类,穿着描述得比较性感吧,杀人方式是通过比较长的细针,从脖子后面一个精巧的位置插入,可以造成是未知原因死亡的假象,可能会推断成心梗之类的,这里有个前置的细节,就是青豆是乘坐一辆很高级的出租车,内饰什么的都非常有质感,有点不像一辆出租车,然后车里放了一首比较小众的歌,雅纳切克的《小交响曲》,但是青豆知道它,这跟后面的情节也有些许关系,这是女主人公青豆的出场;相应的男主的出场印象不是太深刻,男主叫天吾,是个不知名的作家,跟一个叫小松的编辑有比较好的关系,虽然天吾还没有拿到比较有分量的奖项,但是小松很看好他,也让他帮忙审校一个新作家奖的投稿文章,虽然天吾自身还没获得过这个奖,天吾还有个正式工作,是当数学老师,天吾在学生时代是个数学天才,但后面有对文学产生了兴趣,文学还不足以养活自己,靠着教课还是能保持温饱;
接下来是正式故事的起点了,就是小松收到了一部小说投稿,名叫《空气蛹》,是个叫深绘里的女孩子投的稿,小松对他赋予了很高的评价,这里好像记岔了,好像是天吾对这部小说很有好感,但是小松比较怀疑,然后小松看了之后也有了浓厚的兴趣,这里就是开端了,小松想让天吾来重写润色这部《空气蛹》,因为故事本身很有分量,但是描写手法叙事方式等都很拙劣,而天吾正好擅长这个,小松对天吾的评价是,描写技巧无可挑剔,就是故事主体的火花还没际遇迸发,需要一个导火索,这个就可以类比我们程序员,很多比较初中级的程序员主要擅长在原来的代码上修修改改或者给他分配个小功能,比较高级的程序员就需要能做一些项目的架构设计,核心的技术方案设计,以前我也觉得写文档这个比较无聊,但是当一个项目真的比较庞大,复杂的时候,整体和核心部分的架构设计和方案还是需要有文档沉淀的,不然别人不知道没法接受,自己过段时间也会忘记。
对于小松的这个建议,他的初衷是想搅一搅这个死气沉沉套路颇深的文坛,因为本身《空气蛹》这部小说的内容很吸引人,小松想通过天吾的润色补充让这部小说冲击新人奖,有种恶作剧的意图,天吾对此表示很多担心和顾虑,小松的这个建议其实也是一种文学作假,有两方面的担心,一方面是原作者深绘里是否同意如此操作,一方面是外界如果发现了这个事实会有什么样的后果,但是小松表示不用担心,前一步由小松牵线,让天吾跟原作者深绘里当面沟通这个代写是否被允许,结果当然是被允许了,这里有了对深绘里的初步描写,按我的理解是比较仙的感觉,然后语言沟通有些吃力,或者说有她自己的特色,当面沟通时貌似是让深绘里回去再考虑下,然后后面再由天吾去深绘里寄宿的戎野老师家沟通具体的细节。
2019年12月18日23:37:19 更新
去到戎野老师家之后,天吾知道了关于深绘里的一些事情,深绘里的父亲与戎野老师应该是老友,深绘里的父亲在当初成立了一个叫”先驱”的公社,一个独立运行的社会组织,以运营农场作为物资来源,追求更为松散的共同体,即不过分激进地公有制,进行松散的共同生活,承认私有财产,简而言之就是这样一个能稳定存活下来的独立社会组织,但是随着稳定运行,内部的激进派和稳健派开始出现分歧,不可磨合,后来两派就分裂了,深绘里的父亲,深田保留在了稳健派,但是此时其实深田保内心是矛盾的,以为一开始其实是他倡导的独立革命才组织起了这群人,然而现在他又认清了现实社会已经不太相信能通过革命来独立的可能性,后来激进派便开始越加封闭,而且进行军事训练和思想教育,而后这个先驱的激进派别便有了新的名字”黎明”,深绘里也是在此时从先驱逃离来投靠戎野老师
暂时先写到这,未完待续~
这篇年终总结本来应该在农历过完年就出来的,结果是对没有受疫情影响的春节放假时间空闲情况预估太良好,虽然公司调了几天假,但是因为春节期间疫情状况比较好,本来酒店都不让接待聚餐什么的,后来统统放开,结果就是从初一到初六每天要不就是去亲戚家,要不就是去酒店饭店吃饭,计划很丰满,现实很骨感,时间感觉一下就没了,然后年后感觉有点犯懒了,所以才拖到现在。
去年(19 年)的时候跑步突破了 300 公里,然后20 年给自己定了个 400 公里的目标,结果意料之中的没成功,原因可能疫情算一点吧,后面买了跑步机之后,基本周末回家都能跑一下,但是最后还是只跑了300 多公里,总的keep 记录跑量也没超过 1000 公里,所以跑步这个目标还是没成功的,不过还算是比去年多跑一点,这样也算后面好突破点,后面的目标就不定的太高了,每年能比前一年多一点就好,其实跑步已经从一种减肥方式变成一种习惯了,一周一次的跑步已经比较难有效减重了,但是对于保持精力和身体状态还是很有效和重要的,只是对于目前的体重还是要多减下去一些跑步才好,太重了对膝盖负担太大了,可惜还是时间呐,游泳骑车什么的都需要更苛刻的条件和时间,饮食呢控制起来比较难(贪吃
终于在 3 月底之前跑到了 1000 公里,迟了三个月,不过也总算达到了,只是体重控制还是不行,有试着走走楼梯,但是感觉对膝盖负担比较大,得再想想用什么方式

一直提不起笔来写这篇年终总结还有个比较大的原因是觉得20 年的成长不如预期,大小目标都没怎么完成,比如深入了解 jvm,是想能有些深入的见解,而不再是某些点的比较片面的理解,系统性的归纳总结也比较少,每个方向或多或少有些看法和理解,但是不全面,一些东西看过了也会忘记,需要温故而知新,比如 AQS 的内容,第一次读其实理解比较浅,后面就强迫自己去读,去写,才有了一些比之前更深入的理解,因为很多文章都是带有作者思路的引导,适不适合自己都要看是否能从他的思路把它看懂,有些就差别很大,这个跟看书也一样,有些书大众一致推荐,一般情况下大多是经典的好的,但是也有可能是不太适合自己的,可能有时候机缘巧合看到的反而让人茅塞顿开,在 todo 里已经积攒了好多的点和面需要去学习实践,一方面是自己懒,一方面是时间也相对偏少,看看 21 年能不能有所提升,加强“时间管理”,哈哈
技术上主要是看了 mysql 的 mvcc 相关内容,rocketmq 的,redis 的代码,还有 mybatis 等,其实每一个都能写很多,也有很多值得学习的,需要全面系统学习,之前想好好画一个思维导图,将整个技术体系都梳理下,还只做了一点点,方式也有点问题,应该从大到小,而不是深度优先,细节有很多,每一个方面都有自己比较熟悉擅长的,也有不太了解的,可以做一个评分,这个也是亟待改善的,希望今年能完成。
博客方面 20 年一年整是写了 53 篇,差不多是一周一篇的节奏,这个还是不错的,虽然博客质量参差不齐,但是这个更新频率还是比较好的,并且也定了个潜规则,可以一周技术一周生活,这样能缓解水文的频率,提高些技术文章的质量,虽然结果并没有好多少,不过感觉还是可以这么坚持的,能提高一些技术文章的质量那就更好了
]]>年初换了个公司,也算换了个环境,跟前公司不太一样,做的事情方向也不同,可能是侧重点不同,一开始有些不适应,主要是压力上,会觉得压力比较大,但是总体来说与人相处的部分还是不错的,做的技术方向还是Java,这里也感谢前东家让我有机会转了Java,个人感觉杭州整个市场还是Java比较有优势,不过在开始的时候总觉得对Java有点不适应,应该值得深究的东西还是很多的,而且对于面试来说,也是有很多可以问的,后面慢慢发现除开某里等一线超一线互联网公司之外,大部分的面试还是有大概的套路跟大纲的,不过更细致的则因人而异了,面试有时候也还看缘分,面试官关注的点跟应试者比较契合的话就很容易通过面试,不然的话总会有能刁难或者理性化地说比较难回答的问题。这个后面可以单独说一下,先按下不表。
刚进公司没多久就负责比较重要的项目,工期也比较紧张,整体来说那段时间的压力的确是比较大的,不过总算最后结果不坏,这里应该说对一些原来在前东家都是掌握的不太好的部分,比如maven,其实maven对于java程序员来说还是很重要的,但是我碰到过的面试基本没问过这个,我自己也在后面的面试中没问过相关的,不知道咋问,比如dependence分析、冲突解决,比如对bean的理解,这个算是我一直以来的疑问点,因为以前刚开始学Java学spring,上来就是bean,但是bean到底是啥,IOC是啥,可能网上的文章跟大多数书籍跟我的理解思路不太match,导致一直不能很好的理解这玩意,到后面才理解,要理解这个bean,需要有两个基本概念,一个是面向对象,一个是对象容器跟依赖反转,还是只说到这,后面可以有专题说一下,总之自认为技术上有了不小的长进了,方向上应该是偏实用的。这个重要的项目完成后慢慢能喘口气了,后面也有一些比较紧急且工作量大的,不过在我TL的帮助下还是能尽量协调好资源。
后面因为项目比较多,缺少开发,所以也参与帮忙做一些面试,这里总体感觉是面的候选人还是比较多样的,有些工作了蛮多年但是一些基础问题回答的不好,有些还是在校学生,但是面试技巧不错,针对常见的面试题都有不错的准备,不过还是觉得光靠这些面试题不能完全说明问题,真正工作了需要的是解决问题的人,而不是会背题的,退一步来说能好好准备面试还是比较重要的,也是双向选择中的基本尊重,印象比较深刻的是参加了去杭州某高校的校招面试,感觉参加校招的同学还是很多的,大部分是20年将毕业的研究生,挺多都是基础很扎实,对比起我刚要毕业时还是很汗颜,挺多来面试的同学都非常不错,那天强度也很大,从下午到那开始一直面到六七点,在这祝福那些来面试的同学,也都不容易的,能找到心仪的工作。
这一年前大半部分还是比较焦虑不能恢复那种主动找时间学习的状态,可能换了公司是主要的原因,初期有个适应的过程也比较正常,总体来说可能是到九十月份开始慢慢有所改善,对这些方面有学习了下,
住的地方没变化,主要是周边设施比较方便,暂时没找到更好的就没打算换,主要的问题是没电梯,一开始没觉得有啥,真正住起来还是觉得比较累的,希望后面租的可以有电梯,或者楼层低一点,还有就是要通下水道,第一次让师傅上门,花了两百大洋,后来自学成才了,让师傅通了一次才撑了一个月就不行了,后面自己通的差不多可以撑半年,还是比较有成就感的😀,然后就是跑步了,年初的时候去了紫金港跑步,后面因为工作的原因没去了,但是公司的跑步机倒是让我重拾起这个唯一的运动健身项目,后面因为肠胃问题,体重也需要控制,所以就周末回来也在家这边坚持跑步,下半年的话基本保持每周一次以上,比较那些跑马拉松的大牛还是差距很大,不过也是突破自我了,有一次跑了12公里,最远的距离,而且后面感觉跑十公里也不是特别吃不消了,这一年达成了300公里的目标,体重也稍有下降,比较满意的结果。
希望工作方面技术方面能有所长进,生活上能多点时间陪家人,继续跑步减肥,家人健健康康的,嗯
]]>这一年做的最让自己满意的应该就是看了一些书,由折腾群洋总发起的读书打卡活动,到目前为止已经读完了这几本书,《cUrl 必知必会》,《古董局中局 1》,《古董局中局 2》,《算法图解》,《每天 5 分钟玩转 Kubernetes》《幸福了吗?》《高可用可伸缩微服务架构:基于 Dubbo、Spring Cloud和 Service Mesh》《Rust 权威指南》后面可以写个专题说说看的这些书,虽然每天打卡如果时间安排不好,并且看的书像 rust 这样比较难的话还是会有点小焦虑,不过也是个调整过程,一方面可以在白天就抽空看一会,然后也不必要每次都看很大一章,注重吸收。
技术上的成长的话,有一些比较小的长进吧,对于一些之前忽视的 synchronized,ThreadLocal 和 AQS 等知识点做了下查漏补缺了,然后多了解了一些 Java 垃圾回收的内容,但是在实操上还是比较欠缺,成型的技术方案,架构上所谓的优化也比较少,一些想法也还有考虑不周全的地方,还需要多花时间和心思去学习加强,特别是在目前已经有的基础上如何做系统深层次的优化,既不要是鸡毛蒜皮的,也不能出现一些不可接受的问题和故障,这是个很重要的课题,需要好好学习,后面考虑定一些周期性目标,两个月左右能有一些成果和总结。
另外一部分是自己的服务,因为 ucloud 的机器太贵就没续费了,所以都迁移到腾讯云的小机器上了,顺便折腾了一点点 traefik,但是还很不熟练,不太习惯这一套,一方面是 docker 还不习惯,这也加重了对这套环境的不适应,还是习惯裸机部署,另一方面就是 k8s 了,家里的机器还没虚拟化,没有很好的条件可以做实验,这也是读书打卡的一个没做好的点,整体的学习效果受限于深度和实操,后面是看都是用 traefik,也找到了一篇文章可以 traefik 转发到裸机应用,因为主仓库用的是裸机的 gogs。
还有就是运动减肥上,唉,这又是很大的一个痛点,基本没效果,只是还算稳定,昨天看到一个视频说还需要力量训练来增肌,以此可以提升基础代谢,打算往这个方向尝试下,因为今天没有疫情限制了,在 6 月底完成了 200 公里的跑步小目标,只是有些膝盖跟大腿根外侧不适,抽空得去看下医生,后面打算每天也能做点卷腹跟俯卧撑。
下半年还希望能继续多看看书,比很多网上各种乱七八糟的文章会好很多,结合豆瓣评分,找一些评价高一些的文章,但也不是说分稍低点的就不行,有些也看人是不是适合,一般 6 分以上评价比较多的就可以试试。
]]>另外一件是就是蜗壳,从前不知道黝黑蜗壳是啥意思,只是经常会在他的视频里看到,大学的时候在缘网下了一个集锦,炒鸡帅气,各种空接扣篮,越来越能明白那句“你永远不知道意外和明天不知道哪个会先来,且行且珍惜”的含义,只是听了很多道理,依然活不好这一生,知易行难,王阳明真的是这方面的大师,有空可以看看这方面的书,一直想写写我跟篮球跟蜗壳的这十几年,争取能早日写好吧,不过得找个静得下来的时候写。
正事方面上半年还是挺让人失望的,没有达成一些目标,应该还是能力不足吧,技术方面分析一下还是停留在看的表面层,有些实操的,或者结合业务场景的能力不太行,算是在坚持写写 blog,主要是被这个每周一篇的目标推着走,有时会比较焦虑,内容产出也还比较差,希望能在后面有些改善,可能会降低频率,只是觉得降低了也不一定能有比较好的提升,无法战胜自己的惰性,所以暂时还是坚持下这个目标吧,还有就是 coding 能力,有时候也应该刷刷题,提升思维敏捷度,大脑用太少可能生锈了,况且本来就不是很有优势,虽然失望也只能继续努力吧,日拱一卒,来日方长,加油吧~😔
还有就是跑步减肥了,截止今天,上半年跑了 136 公里了,因为疫情影响,农历年后是从 4 月 17 号开始跑的,去年跑到了 300 公里,奖励自己了一个手表(真的挺后悔的,还不如 200 块买个手表),今年希望可以能在这个基础上再进一步,一直跟领导说,跑步算是我坚持下来的唯一一个好习惯了,618 买了个跑步机,周末回家了可以不受天气影响的多跑跑,不过如果天气好可能还是会出去跑跑,跑步机跑道多少还是有点拘束,只是感觉可能是我还是吃得太多了🤦♂️,效果不是很明显,还在 80 这个坎徘徊,等于浪费了大半年,可能是年初的项目太费心力,压力比较大,吃得更多,是不是可以算工伤😄,这方面也需要好好调整,可以放得开一点,虽然不太可能一下子到位,但是总要去努力下,随着年龄成长总要承担更多,也要看得开一点,没法事事如愿,尽力就好了,减肥这个事情还在结合一些俯卧撑啥的,希望也能坚持下去,加油吧,不知道原话怎么说的,意思是人类最大的勇敢就是看透了人世间的苦难,仍然热爱生活。我当然没可能让内心变得这么强大,试着去努力吧,奥力给!
]]>工作没什么大变化,有了些微的提升,可能因为是来了之后做了些项目对比公司与来还算是比较重要的,但是技术难度上没有特别突出的点,可能最开始用 openresty+lua 做了个 ab 测的工具,还是让我比较满意的,后面一般都是业务型的需求,今年可能在业务相关的技术逻辑上有了一些深度的了解,而原来一直想做的业务架构升级和通用型技术中间件这样的优化还是停留在想象中,前面说的 ab 测应该算是个半成品,还是没能多走出这一步,得需要多做一些实在的事情,比如轻量级的业务框架,能够对原先不熟悉的业务逻辑,代码逻辑有比较深入的理解,而不是一直都是让特定的同学负责特定的逻辑,很多时候还是在偷懒,习惯以一些简单安全的方案去做事情,在技术上还是要有所追求,还有就是能够在新语言,主要是 rust,swift 这类的能有些小玩具可以做,rust 的话是因为今年看了一本相关的书,后面三分之一其实消化得不好,这本书整体来说是很不错的,只是 rust 本身在所有权这块,还有引用包装等方面是设计得比较难懂,也可能是我基础差,所以还是想在复习下,可以做一个简单的命令行工具这种,然后 swift 是想说可以做点 mac 的小软件,原生的毕竟性能好点,又小。基于 web 做的客户端大部分都是又丑又大,极少数能好看点,但也是很重,起码 7~80M 的大小,原生的估计能除以 10。
整体的职业规划貌似陷入了比较大的困惑期,在目前公司发展前景不是很大,但是出去貌似也没有比较适合我的机会,总的来说还是杭州比较卷,个人觉得有自己的时间是非常重要的,而且这个不光是用来自我提升的,还是让自己有足够的时间做缓冲,有足够的时间锻炼减肥,时间少的情况下,不光会在仅有的时间里暴饮暴食,还没空锻炼,身体是革命的本钱,现在其实能特别明显地感觉到身体状态下滑,容易疲劳,焦虑。所以是否也许有可能以后要往外企这类的方向去发展。
工作上其实还是有个不大不小的缺点,就是容易激动,容易焦虑,前一点可能有稍稍地改观,因为工作中的很多现状其实是我个人难以改变的,即使觉得不合理,但是结构在那里,还不如自己放宽心,尽量做好事情就行。第二点的话还是做得比较差,一直以来抗压能力都比较差,跟成长环境,家庭环境都有比较大的关系,而且说实在的特别是父母,基本也没有在这方面给我正向的帮助,比较擅长给我施压,从小就是通过压力让我好好读书,当个乖学生,考个好学校,并没有能真正地理解我的压力,教我或者帮助我解压,只会在那说着不着边际的空话,甚至经常反过来对我施压。还是希望能慢慢解开,这点可能对我身体也有影响,也许需要看一些心理疏导相关的书籍。工作篇暂时到这,后续还有其他篇,未完待续哈哈😀
Given a sorted array of integers, find the starting and ending position of a given target value.
Your algorithm’s runtime complexity must be in the order of O(log n).
If the target is not found in the array, return [-1, -1].
For example,
Given [5, 7, 7, 8, 8, 10] and target value 8,
return [3, 4].
一开始就想到了二分查找,但是原来做二分查找的时候一般都是找到确定的那个数就完成了,
这里的情况比较特殊,需要找到整个区间,所以需要两遍查找,并且一个是找到小于target
的最大索引,一个是找到大于target的最大索引,代码参考leetcode discuss,这位仁
兄也做了详细的分析解释。
class Solution { |
synchronized 实现的,后面我也贴下代码
import java.util.concurrent.locks.Condition; |
介绍下 Condition 的结构
public class ConditionObject implements Condition, java.io.Serializable { |
主要的就这么点,而且也复用了 AQS 阻塞队列或者大大叫 lock queue中同样的 Node 节点,只不过它没有使用其中的双向队列,也就是prev 和 next,而是在 Node 中的 nextWaiter,所以只是个单向的队列,没使用 next 其实还有个用处,后面会提到,看下结构的示意图
然后主要是看两个方法,await 和 signal,
先来看下 await
/** |
添加条件队列节点
/** |
清理取消的节点
/** |
完全释放锁
/** |
判断是否在阻塞队列中
/** |
await 的逻辑差不多就是这样子,主要的就是把自己包成一个 Node 节点,waitStatus 的状态是 CONDITION,挂在等待队列的最后,然后完全释放锁,park 等待
/** |
这里其实就是把 condition 等待队列的第一个未取消的节点入队到阻塞队列去争锁
synchronized 版的 BoundedBuffer
/* |
第一个线程抢到锁了,此时state跟阻塞队列是怎么样的,其实这里是之前没理解对的地方
/** |
当第二个线程进来的时候应该是怎么样,结合代码来看
/** |
然后来看下addWaiter的逻辑
/** |
然后就是enq的逻辑了
/** |
所以从这里可以看出来,其实head头结点不是个真实的带有线程的节点,并且不是在第一个线程进来的时候设置的
通过代码来看下
/** |
// 头结点,你直接把它当做 当前持有锁的线程 可能是最好理解的 |
大概了解了 aqs 底层的双向等待队列,
结构是这样的
每个 node 里面主要是的代码结构也比较简单
static final class Node { |
其实可以主要关注这个 waitStatus 因为这个是后面的节点给前面的节点设置的,等于-1 的时候代表后面有节点等待,需要去唤醒,
这里使用了一个变种的 CLH 队列实现,CLH 队列相关内容可以查看这篇 自旋锁、排队自旋锁、MCS锁、CLH锁
You are given two linked lists representing two non-negative numbers. The digits are stored in reverse order and each of their nodes contain a single digit. Add the two numbers and return it as a linked list.
Input:(2 -> 4 -> 3) + (5 -> 6 -> 4)
Output: 7 -> 0 -> 8
分析(不用英文装逼了)
这个代码是抄来的,链接原作是这位大大。
一开始没看懂题,后来发现是要进位的,自己写的时候想把长短不同时长的串接到结果
串的后面,试了下因为进位会有些问题比较难搞定,这样的话就是在其中一个为空的
时候还是会循环操作,在链表太大的时候可能会有问题,就这样(逃
原来是有个小错误没发现,改进后的代码也AC了,棒棒哒!
/** |
/** |
-Denv=fat,而在我们的环境配置中 fat 就是代表测试环境, 其实应该是-Denv=pro,而 apollo 总共有这些环境
public enum Env{ |
而这些解释
/** |
那如果要在运行时知道 apollo 当前使用的环境可以用这个
Env apolloEnv = ApolloInjector.getInstance(ConfigUtil.class).getApolloEnv(); |
简单记录下。
]]>EnableApolloConfig 注解
|
这个 import 实现了
public class ApolloConfigRegistrar implements ImportBeanDefinitionRegistrar { |
然后就调用了
com.ctrip.framework.apollo.spring.spi.DefaultApolloConfigRegistrarHelper#registerBeanDefinitions |
接着是注册了这个 bean,com.ctrip.framework.apollo.spring.config.PropertySourcesProcessor
|
而com.ctrip.framework.apollo.spring.config.PropertySourcesProcessor 实现了 org.springframework.beans.factory.config.BeanFactoryPostProcessor
它里面的 com.ctrip.framework.apollo.spring.config.PropertySourcesProcessor#postProcessBeanFactory 方法就会被 spring 调用,
private void initializePropertySources() { |
然后是 com.ctrip.framework.apollo.ConfigService#getConfig
接着就是它
com.ctrip.framework.apollo.internals.DefaultConfigManager#getConfig
|
创建配置
com.ctrip.framework.apollo.spi.DefaultConfigFactory#create |
然后
LocalFileConfigRepository createLocalConfigRepository(String namespace) { |
然后是创建远程配置仓库
com.ctrip.framework.apollo.spi.DefaultConfigFactory#createRemoteConfigRepository |
继续对当前的 namespace 创建远程配置仓库
com.ctrip.framework.apollo.internals.RemoteConfigRepository#RemoteConfigRepository |
然后是同步配置,下面的日志异常经常可以看到,比如配置拉取地址不通
com.ctrip.framework.apollo.internals.AbstractConfigRepository#trySync |
实际的同步方法,加了synchronized 锁,
com.ctrip.framework.apollo.internals.RemoteConfigRepository#sync |
然后走到这
com.ctrip.framework.apollo.internals.RemoteConfigRepository#loadApolloConfig |
com.ctrip.framework.apollo.internals.RemoteConfigRepository#getConfigServices |
com.ctrip.framework.apollo.internals.ConfigServiceLocator#getConfigServices |
更新配置服务
com.ctrip.framework.apollo.internals.ConfigServiceLocator#updateConfigServices |
com.ctrip.framework.apollo.spring.annotation.SpringValueProcessor#processField
|
然后我们看下这个springValueRegistry是啥玩意
public class SpringValueRegistry { |
这类其实就是个 map 来存放 springvalue,然后有com.ctrip.framework.apollo.spring.property.AutoUpdateConfigChangeListener来监听更新操作,当有变更时
|
其实原理很简单,就是得了解知道下
]]>Clone a graph. Input is a Node pointer. Return the Node pointer of the cloned graph. |
typedef unordered_map<Node *, Node *> Map; |
using the Breadth-first traversal
and use a map to save the neighbors not to be duplicated.
比如这样子
我的对象是Entity
public class Entity { |
Comparator
public class MyComparator implements Comparator { |
比较代码
private static MyComparator myComparator = new MyComparator(); |
看到这里的e2的排序值是null,在Comparator中如果要正常运行的话,就得判空之类的,这里有两点需要,一个是不想写这个MyComparator,然后也没那么好排除掉list里排序值,那么有什么办法能解决这种问题呢,应该说java的这方面真的是很强大

看一下nullsFirst的实现
final static class NullComparator<T> implements Comparator<T>, Serializable { |
核心代码就是下面这段,其实就是帮我们把前面要做的事情做掉了,是不是挺方便的,小记一下哈
]]>ArrayBlockingQueue,因为这个阻塞队列是使用了锁来控制阻塞,关于并发其实有一些通用的最佳实践,就是用锁,即使是 JDK 提供的锁,也是比较耗资源的,当然这是跟不加锁的对比,同样是锁,JDK 的实现还是性能比较优秀的。常见的阻塞队列中例如 ArrayBlockingQueue 和 LinkedBlockingQueue 都有锁的身影的存在,区别在于 ArrayBlockingQueue 是一把锁,后者是两把锁,不过重点不在几把锁,这里其实是两个问题,一个是所谓的 lock free, 对于一个单生产者的 disruptor 来说,因为写入是只有一个线程的,是可以不用加锁,多生产者的时候使用的是 cas 来获取对应的写入坑位,另一个是解决“伪共享”问题,后面可以详细点分析,先介绍下使用public class LongEvent { |
事件生产
public class LongEventFactory implements EventFactory<LongEvent> |
事件处理器
public class LongEventHandler implements EventHandler<LongEvent> { |
主方法代码
package disruptor; |
运行下可以看到运行结果
这里其实就只是最简单的使用,生产者只有一个,然后也不是批量的。
com.lmax.disruptor.RingBuffer#addGatingSequences 这个方法里添加com.lmax.disruptor.dsl.Disruptor#handleEventsWith(com.lmax.disruptor.EventHandler<? super T>...)com.lmax.disruptor.dsl.Disruptor#createEventProcessors(com.lmax.disruptor.Sequence[], com.lmax.disruptor.EventHandler<? super T>[])
EventHandlerGroup<T> createEventProcessors( |
在 BatchEventProcessor 在类内有个定义 sequence
private final Sequence sequence = new Sequence(Sequencer.INITIAL_CURSOR_VALUE); |
然后在上面循环中的这一句取出来
processorSequences[i] = batchEventProcessor.getSequence(); |
调用com.lmax.disruptor.dsl.Disruptor#updateGatingSequencesForNextInChain 方法
private void updateGatingSequencesForNextInChain(final Sequence[] barrierSequences, final Sequence[] processorSequences) |
而如何更新则是在处理器 com.lmax.disruptor.BatchEventProcessor#run 中
public void run() |
然后是
private void processEvents() |
lock free , 相比于前面介绍的两个阻塞队列,false sharing 的情况,也就是常说的 伪共享 问题,那么什么叫 伪共享 呢,Cache Miss 就再往下一级 Cache 读取,Cache Line 读取,并且也遵循了“就近原则”,false sharing,ArrayBlockingQueue,需要有 takeIndex , putIndex , count , 因为在同一个类中,Cache Line 中,但是这几个值会被不同的线程修改,false sharing这种情况disruptor 中则使用了填充的方式,让我的头指针能够不产生false sharing
class LhsPadding |
通过代码可以看到,sequence 中其实真正有意义的是 value 字段,因为需要在多线程环境下可见也
使用了volatile 关键字,而 LhsPadding 和 RhsPadding 分别在value 前后填充了各
7 个 long 型的变量,long 型的变量在 Java 中是占用 8 bytes,这样就相当于不管怎么样,
value 都会单独使用一个缓存行,使得其不会产生 false sharing 的问题。
<dubbo:registry address="zookeeper://127.0.0.1:2181" register="false" /> |
就是只要 register="false" 就可以了,这样比如我们在开发环境想运行服务,但又不想让开发环境正常的请求调用到本地来,当然这不是唯一的方式,通过 dubbo 2.7 以上的 tag 路由也可以实现或者自行改造拉取和注册服务的逻辑,因为注册到注册中心的其实是一串带参数的 url,还是比较方便改造的。相反的就是只注册,不拉取
<dubbo:registry address="zookeeper://127.0.0.1:2181" subscribe="false" /> |
这个使用场景就是如果我这个服务只作为 provider,没有任何调用其他的服务,其实就可以这么设置
<dubbo:provider loadbalance="random" weight="50"/> |
首先这是在使用了随机的负载均衡策略的时候可以进行配置,并且是对于多个 provider 的情况下,这样其实也可以部分解决上面的只拉取不注册的问题,我把自己的权重调成 0 或者很低
]]>
|
重点看 servlet 的 service方法,就是接受请求,处理完了给响应,不说细节,不然光 Tomcat 的能说半年,所以呢再进一步去理解,其实就能知道,就是一个先后的问题,盗个图
filter 跟后两者最大的不一样其实是一个基于 servlet,在非常外层做的处理,然后是 interceptor 的 prehandle 跟 posthandle,接着才是我们常规的 aop,就这么点事情,做个小试验吧(还是先补段代码吧)
// ---------------------------------------------------- FilterChain Methods |
注意看这一行filter.doFilter(request, response, this);
是不是看懂了,就是个 filter 链,但是这个代码在哪呢,org.apache.catalina.core.ApplicationFilterChain#doFilter
然后是interceptor,
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception { |
代码在哪呢,org.springframework.web.servlet.DispatcherServlet#doDispatch,然后才是我们自己写的 aop,是不是差不多明白了,嗯,接下来是例子
写个 filter
public class DemoFilter extends HttpServlet implements Filter { |
因为用的springboot,所以就不写 web.xml 了,写个配置类
|
然后再来个 interceptor 和 aop,以及一个简单的请求处理
public class DemoInterceptor extends HandlerInterceptorAdapter { |
好了,请求一下,看看 stdout,
搞定完事儿~
这里主要介绍这个比较新的垃圾回收器,在 G1 之前的垃圾回收器都是基于如下图的内存结构分布,有新生代,老年代和永久代(jdk8 之前),然后G1 往前的那些垃圾回收器都有个分代,比如 serial,parallel 等,一般有个应用的组合,最初的 serial 和 serial old,因为新生代和老年代的收集方式不太一样,新生代主要是标记复制,所以有 eden 跟两个 survival区,老年代一般用标记整理方式,而 G1 对这个不太一样。
看一下 G1 的内存分布
可以看到这有很大的不同,G1 通过将内存分成大小相等的 region,每个region是存在于一个连续的虚拟内存范围,对于某个 region 来说其角色是类似于原来的收集器的Eden、Survivor、Old Generation,这个具体在代码层面
// We encode the value of the heap region type so the generation can be |
hotspot/share/gc/g1/heapRegionType.hpp
当执行垃圾收集时,G1以类似于CMS收集器的方式运行。 G1执行并发全局标记阶段,以确定整个堆中对象的存活性。标记阶段完成后,G1知道哪些region是基本空的。它首先收集这些region,通常会产生大量的可用空间。这就是为什么这种垃圾收集方法称为“垃圾优先”的原因。顾名思义,G1将其收集和压缩活动集中在可能充满可回收对象(即垃圾)的堆区域。 G1使用暂停预测模型来满足用户定义的暂停时间目标,并根据指定的暂停时间目标选择要收集的区域数。
由G1标识为可回收的区域是使用撤离的方式(Evacuation)。 G1将对象从堆的一个或多个区域复制到堆上的单个区域,并在此过程中压缩并释放内存。撤离是在多处理器上并行执行的,以减少暂停时间并增加吞吐量。因此,对于每次垃圾收集,G1都在用户定义的暂停时间内连续工作以减少碎片。这是优于前面两种方法的。 CMS(并发标记扫描)垃圾收集器不进行压缩。 ParallelOld垃圾回收仅执行整个堆压缩,这导致相当长的暂停时间。
需要重点注意的是,G1不是实时收集器。它很有可能达到设定的暂停时间目标,但并非绝对确定。 G1根据先前收集的数据,估算在用户指定的目标时间内可以收集多少个区域。因此,收集器具有收集区域成本的合理准确的模型,并且收集器使用此模型来确定要收集哪些和多少个区域,同时保持在暂停时间目标之内。
注意:G1同时具有并发(与应用程序线程一起运行,例如优化,标记,清理)和并行(多线程,例如stw)阶段。Full GC仍然是单线程的,但是如果正确调优,您的应用程序应该可以避免Full GC。
在前面那篇中在代码层面简单的了解了这个可预测时间的过程,这也是 G1 的一大特点。
]]>第一个就是默认这个是需要 https 的,所以需要给 derper 服务申请个域名,或者有了域名就加个解析,比如 dp.hello.com,申请完域名就需要申请证书了,这个刚好就学习下使用 acme.sh这个工具,还是非常不错的,我用的是腾讯云的域名解析服务,其实是收购的 dnspod 的服务,acme.sh 安装就很简单,一条命令
`
curl https://get.acme.sh | sh |
然后成功了之后就要把.zshrc 生效下,默认会把脚本路径加入到当前的 shell 的 rc 文件里,然后就是申请证书,但是有两种方式,一种就是在域名指定的 ip 机器对应的访问路径下放置验证的文件
acme.sh --issue -d domain.tld -d www.domain.tld --webroot /home/wwwroot/domain.tld/ |
比如这样指定 webroot,另一个中更方便的方式就是通过 dns 认证的方式,我这边以 dnspod 举例,这边要特别注意的是 dnspod 虽然被腾讯云收购,但是这个方式还是需要用 dnspod 原来自己的 api token 验证的

然后拿到生成的 id 跟 token 设置到环境变量里,需要保存好这个 token,后面是看不到了的
export DP_Id=123456 |
然后就可以用命令进行验证了
acme.sh --issue --dns dns_dp -d xxx.hello.com |
这个是 dnspod 家的,其他的也可以在这里找到验证方式
申请完成后会把证书放在用户目录下的.acme.sh 目录中,记得把cer文件改成 crt,并且文件名只能是域名 xxx.hello.com.crt,我没试过其他的行不行,从别的文章里看到需要一致,然后就是启动 derper 了
我们通过 docker 的方式,
sudo docker run --restart always \ |
前一个端口 12345可以自己随意定,后面$dir改成自己的.acme.sh目录所在的路径,然后
-v /run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock \ 这一行 和-e DERP_VERIFY_CLIENTS=true \ 是为了能够让 derper 能够安全一些,就是在本机开一个 tailscale 客户端,连接接到 headscale 服务,可以参考前面的添加节点,然后把这个启动客户端的进程映射进docker里面,因为本身 derper 就没有特别的认证逻辑,所以就让同一个headscale服务的客户端进程来验证是属于同一个headscale服务的节点才允许加入中转,实际这样就跑起来了一个 derper 服务这样可以用 docker 命令查看日志
sudo docker logs -f derper 查看是不是有问题,然后如果没有问题的话还不一定代表 derper 起来了,比较直接的方法就是直接打开域名加上端口的地址,比如 xxxx.hello.com:12345 这个,

显示这个就代表服务已经正常启动运行了,然后就是需要修改 headscale 的配置文件了,首先要设置 derper 的配置文件,类似这样
regions: |
regionid表示区域 id,一个区域下可以后多个 node,node的 name 是节点的唯一识别码,ipv4 可以不填,有 hostname 就可以,然后stunonly 是 false 表示不只使用 stun还可以使用 derp
然后就是修改 headscale 自身的配置文件,把共用的 derper 配置改成

上面的 urls 注释掉,后面的 paths 添加刚才的配置文件路径,这样就可以了,至于连接是不是走的这个
可以用 tailscale netcheck 查看最近的 derper 节点已经延迟,看到使用了自己的 derper 就对了
Tailscale 和 Headscale 的方式,就想着试试看,没想到一开始就踩了几个比较莫名其妙的坑。Error initializing error="failed to read or create private key: failed to save private key to disk: open /etc/headscale/private.key: read-only file system" |
其实一开始看到这个我都有点懵了,咋回事呢,read-only file system一般有可能是文件系统出问题了,不可写入,需要重启或者修改挂载方式,被这个错误的错误日志给误导了,后面才知道是配置文件,在另一个教程中也有个类似的回复,一开始没注意,其实就是同一个问题。
默认的配置文件是这样的
|
问题就是出在几个文件路径的配置,默认都是当前目录,也就是headscale的可执行文件所在目录,需要按它配置说明中的生产配置进行修改
# For production: |
直接改成绝对路径就好了,还有两个文件路径
另一个也是个秘钥的路径问题
noise: |
这个问题也是一种误导,
错误信息是
Error initializing error="unable to open database file: out of memory (14)" |
这就是个文件,内存也完全没有被占满的迹象,原来也是文件路径的问题
# For production: |
都改成绝对路径就可以了,然后这里还有个就是要对/var/lib/headscale/和/etc/headscale/等路径赋予headscale用户权限,有时候对这类问题的排查真的蛮头疼,日志报错都不是真实的错误信息,开源项目对这些错误的提示真的也需要优化,后续的譬如mac也加入节点等后面再开篇讲
headscale 在前面两篇初体验和添加节点 主要是介绍了如何搭建和使用,但是这里有个很大的缺点,比如我在想要两地的网络能够连通,但是两地的网络内都不止一个机器,那想让他们连通就需要把它们都加入这个 headscale 所组成的虚拟局域网,并且每个都是这个虚拟局域网的ip,跟原来的 ip 地址不一样会比较难记忆,所以有没有办法不用这么麻烦呢,当然是有的,那就是 headscale 的路由功能。10.0.0.1,另一个节点 B 是 10.0.0.2,在之前的状态下,我的节点 A 只能通过 10.0.0.2 来连接节点 B,如果节点 A 想要连接节点 B 所在地的局域网内部其他节点,我们就可以通过节点 B 的客户端登录的时候开启路由转发,这样节点 B 就会充当一个路由转发的功能,并且不需要通过10.0.0这个网段来访问,直接可以通过节点 B所在的局域网地址来访问,比如192.168.2.10,具体操作就是把客户端启动方式改成命令行的,主要就是 --advertise-routes, 指明需要转发的网段
tailscale up --advertise-routes=192.168.xx.0/24 --accept-dns=false --login-server=http://serverIp:serverPort --unattended |
前面的 192.168.xx.0 就是节点 B 所在局域网的网段,然后 login-server 是 headscale 的服务 ip 跟端口,这个本身客户端就会使用,另外这个还有一个前提的,需要开启服务器的端口转发,对于 Windows 其实默认就可以,Linux 的话就需要设置下
echo 'net.ipv4.ip_forward = 1' | tee /etc/sysctl.d/ipforwarding.conf |
到这里我们只完成了第一步,第二步需要在 headscale 服务端启用这条路由配置
首先可以用 sudo headscale routes 查看当前有的路由sudo headscale routes enable -h 这里看下怎么启用,因为网上有些是用-i 指定哪一条路由的,但是我使用的这个版本是用-r 的sudo headscale routes enable -r 1 然后用这个命令启用就行了

这样我们就能够很方便地在单个节点互连之后访问到对方局域网内的其他节点
caddy,只需要做好域名解析,caddy 就会自动加上https,那么在docker层面就可以不用额外增加证书啥的,各干各的事docker run --restart always --name derper -p 12345:12345 -p 3478:3478/udp -v /run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock -e DERP_ADDR=:12345 -e DERP_DOMAIN=derper.domain.com -e DERP_VERIFY_CLIENTS=true -d dockerproxy.cn/yangchuansheng/derper:latest |
derper.domain.com 需要换成自己的域名,端口也可以自己按需,只是还要注意下 /run/tailscale/tailscaled.sock 这个映射是为了让derper能够识别到这是同一个headscale下的客户端链接,防止被滥用,
curl -fsSL https://tailscale.com/install.sh | sh |
本机通过这个安装下,然后再登录headscale
tailscale up --login-server=http://headscaleip:headscaleport --accept-routes=true --accept-dns=false |
然后找到进程对应的sock文件,把它映射进去
接下去就是做反向代理,第一步先把域名解析做好,不然caddy没法做证书的,感觉caddy真的是懒人福音
derper.domain.com { |
就这几行,是不是超方便,这样就省去了隔段时间要去转换下证书,重启derper的麻烦了,虽然也可以自动化,但是作为一个shell不那么熟练的,又怕权限控制不好,重要目录被删掉的,还是这样比较省力
fullchain.cer 完整证书转成crt格式的
openssl x509 -inform PEM -in fullchain.cer -out derper.demo.com.crt |
这边是PEM格式的证书,如果是DER的话就改一下
openssl x509 -inform DER -in certificate.cer -out certificate.crt |
转换完成后就重新启动下docker
这里的原因主要是fullchain.cer是包含了完整的证书链,而ca.cer只是包含用户证书,所以需要替换一下,这算是个小问题
HeapWord* G1CollectedHeap::do_collection_pause(size_t word_size, |
这里就是收集时需要停顿的,其中VMThread::execute(&op);是具体执行的,真正执行的是VM_G1CollectForAllocation::doit方法
void VM_G1CollectForAllocation::doit() { |
这里可以看到核心的是G1CollectedHeap::do_collection_pause_at_safepoint这个方法,它带上了目标暂停时间的值
G1CollectedHeap::do_collection_pause_at_safepoint(double target_pause_time_ms) { |
往下走就是这一步G1Policy::finalize_collection_set,去处理新生代和老年代
void G1Policy::finalize_collection_set(double target_pause_time_ms, G1SurvivorRegions* survivor) { |
这里分别调用了两个方法,可以看到剩余时间是往下传的,来看一下具体的方法
double G1CollectionSet::finalize_young_part(double target_pause_time_ms, G1SurvivorRegions* survivors) { |
下面是老年代的部分
void G1CollectionSet::finalize_old_part(double time_remaining_ms) { |
上面第三行是个判断,当前是否是 mixed 回收阶段,如果不是的话其实是没有老年代什么事的,所以可以看到代码基本是从这个 if 判断if (collector_state()->in_mixed_phase()) {开始往下走的
先写到这,偏向于做笔记用,有错轻拍
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0)); |
这里我们先看下 COUNT_BITS 它是 Integer.SIZE - 3,Integer.SIZE 这个是 32,也就是代表了 Java 用了四个 Byte 来存一个 Integer, 那么 COUNT_BITS 就是 29,
这个 29 是用了干嘛的呢,逐步往下看,为什么先介绍 COUNT_BITS,因为第一行的 ctl 的值是通过 ctlOf(RUNNING, 0) 算出来的,而 RUNNING 又是通过等于 -1 左移 COUNT_BITS 位来得到,移动 29 位后,还剩下三位,而这三位只需要表示后面五种状态,其中只有 RUNNING 是负值,这样就巧妙的只利用了 ctl 的前三位来存储线程池的状态而后面的 29 位就是用来存储线程数量的,具体怎么取呢,我们在来看下 CAPACITY 它是 (1 << COUNT_BITS) - 1 把 1 左移 29 位后减 1,也就是 536870911,这里再补充下,左移一位就等于是乘以 2,左移 29 位就是乘以 2 的 29 次,减了 1 就是 29 位能存的最大值,代表线程池最大的线程容量,用二进制来表示就是 32 位长度的int,前三位是 0,后 29 位是 1,代表了线程池的容量,那么 runStateOf 和 workerCountOf 的理解就很简单了,runStateOf 是 c 跟 CAPACITY 取反之后的值做”与”操作,CAPACITY 取反就变成了前三位是 1,后面的二十九位是 0,而对于”与”操作,后面的二十九位无论是什么都会被忽略,也就是取了前三位的值workerCountOf 正好相反,直接跟 CAPACITY 做 “与” 操作,也就是取后二十九位的值ctlOf 就是直接对 rs 与 wc 做了 “或” 操作
而前面也提到了只有 RUNNING 是负数,那么就可以直接做大小比较来判断线程池状态
这个可能对很多同学来说是非常简单的,但是对于一部分同学来说就是个拦路虎,希望能对这部分同学有所帮助。
private static final ThreadPoolExecutor threadPoolExecutor = |
MyArrayBlockingQueue 是我复制的 ArrayBlockingQueue 加了点日志,可以认为就是一样的,这种情况下
执行过程是怎么样的呢, 队列长度是 2,核心线程数和最大线程数都是 1,提交任务是采用了两层循环,内层是循环三次,往线程池里提交任务,然后内层循环完了以后会重新睡眠 100 毫秒
在进入下一次外层循环,如果能一眼看出来问题的说明对线程池了解得很深入了,如果没有的话我们就一起来看下
先说下结论,这个代码会出现拒绝异常
考虑下是什么原因呢,是不是我线程数太少了,放大一些,感觉符合直觉一点
修改成
private static final ThreadPoolExecutor threadPoolExecutor = |
然而还是一样
只不过晚了点出现,那么问题出在哪呢
为什么我要去重写这个 MyArrayBlockingQueue,就是为了找到原因,其实很多讲解线程池的都是讲了线程池的参数,什么队列是链表的,数组的
但是没有讲到我是怎么往队列塞任务,怎么从队列取任务的呢
public boolean offer(E e) { |
这里是往队列里塞任务,注意这里需要获得锁,
而对于获取任务呢
public E take() throws InterruptedException { |
注意这里也需要获得锁,当我一个线程池的线程数进入稳定状态,也就是保持一定数量的线程不变的情况下
上面是一种比较可能的情况,即核心线程数等于最大线程数,那么我在提交任务的时候是非常快的
if (command == null) |
再来看下这段代码,第一步只需要判断是否为空,第二步就是判断核心线程数量,明显我说的情况,前面两步就直接过去了
然后就是判断线程池运行状态和往队列里塞任务了,但是线程运行完一个任务主动从队列里获取则需要更多的逻辑
这样就造成了我往队列里塞任务会比获取任务快很多,队列一满,就会抛出拒绝异常
即使我把线程数量放大到 100 还是一样,只不过会出现的慢一点,那么口说无凭,我们来验证下,提交任务过快,那么我在提交
方法里做个延迟
public boolean offer(E e) { |
这样就没啥问题了
除了最后这个加延时,其他的直接用 ArrayBlockingQueue 就可以实验,实操一下会对这个逻辑有更深的理解
An { ExecutorService} that executes each submitted task using |
通过前面的简单翻译我们就能大致略窥得线程池配置全貌,继续看一个构造方法
public ThreadPoolExecutor(int corePoolSize, |
这个构造方法就主要配置了 corePoolSize 核心线程数,maximumPoolSize 最大线程数, keepAliveTime 线程保活时间,unit 时间单位,workQueue 工作队列,而传入后可以看到使用了默认的线程工厂和默认的拒绝处理器
public ThreadPoolExecutor(int corePoolSize, |
最终会执行到这里做一些校验判断,包括几个参数校验和配置赋值
]]>public void execute(Runnable command) { |
这里面比较重要的就是 addWorker 方法,我们也来看一下
这里用到了 break retry; 就是在循环中跳出到这个 retry 的位置继续执行
然后还是获取运行状态,如果是非运行状态,
并且rs == SHUTDOWN 与 firstTask == null 和 ! workQueue.isEmpty(),至少一个为false
因为只有当 SHUTDOWN 状态才会出现后面两者为 false 的情况,如果是 SHUTDOWN ,队列不为空还是需要执行完队列里的任务
然后是判断线程数量与传入参数 core 还有核心线程数跟最大线程数的对比,如果是超过了就返回 false 也就是外层的第一步的内部
if 就会继续执行后面的获取线程池状态,然后是 cas 增加线程数量,如果失败则 break 跳到方法开头,如果成功则继续重新获取 c
判断线程池运行状态,如果不一致则从外层继续进入
后面的就是新建一个 worker,然后获取锁,继续判断线程池状态,如果在运行中或者队列不为空(隐含条件)则继续执行添加 worker
并判断是否需要更新历史最大线程数,更改线程添加状态,然后启动线程,标记线程启动状态
private boolean addWorker(Runnable firstTask, boolean core) { |
后面会继续讲下线程如何执行队列里的任务
]]>addWorker 中runWorker 方法
|
介绍下这个 runWorker 方法
这里就会先处理 firstTask,如果 firstTask 是 null 则会去队列里取
里面会有两个钩子,一个是执行前,一个是执行后,注意这个循环是没有常规
退出逻辑的,说明是一直在往队列里获取,除非获取队列里的任务超时失败了
这样就到最后会去执行 processWorkerExit
final void runWorker(Worker w) { |
而这个 processWorkerExit 也有个比较特殊的逻辑
照理我们会想到这里可能就是线程在处理完队列里的任务
以后,就会判断下是否要退出,如果是核心线程的话就不用
如果是非核心线程就会退出了,但是这里其实有个替换逻辑
就是最后有个 addWorker 调用
private void processWorkerExit(Worker w, boolean completedAbruptly) { |
这里主要讲了线程 Worker 运行的逻辑
]]>private Runnable getTask() { |
阻塞队列的 poll 主要是通过锁,和notEmpty这个 condition 来等待制定的时间
指定时间后开始 dequeue 出队
public E poll(long timeout, TimeUnit unit) throws InterruptedException { |
第二部分比较重要,有的同学的问题是为什么不一开始开到最大线程,而是达到核心线程数后就进队列了,
其实池化技术最简单的原因就是希望能够复用这些线程,因为创建销毁他们的成本太大了,如果直接最大线程数的话
其实都不用用到线程池技术了,直接有多少任务就开多少线程,用完就丢了,阐述下我认为比较重要的概念点
Merge two sorted linked lists and return it as a sorted list. The list should be made by splicing together the nodes of the first two lists.
将两个升序链表合并为一个新的 升序 链表并返回。新链表是通过拼接给定的两个链表的所有节点组成的。

输入:l1 = [1,2,4], l2 = [1,3,4]
输出:[1,1,2,3,4,4]
输入: l1 = [], l2 = []
输出: []
输入: l1 = [], l2 = [0]
输出: [0]
这题是 Easy 的,看着也挺简单,两个链表进行合并,就是比较下大小,可能将就点的话最好就在两个链表中原地合并
public ListNode mergeTwoLists(ListNode l1, ListNode l2) { |

Implement strStr().
Return the index of the first occurrence of needle in haystack, or -1 if needle is not part of haystack.
What should we return when needle is an empty string? This is a great question to ask during an interview.
For the purpose of this problem, we will return 0 when needle is an empty string. This is consistent to C’s strstr() and Java’s indexOf().
Example 1:
Input: haystack = "hello", needle = "ll" |
Example 2:
Input: haystack = "aaaaa", needle = "bba" |
Example 3:
Input: haystack = "", needle = "" |
字符串比较其实是写代码里永恒的主题,底层的编译器等处理肯定需要字符串对比,像 kmp 算法也是很厉害
public int strStr(String haystack, String needle) { |
Given an integer array nums, find the contiguous subarray (containing at least one number) which has the largest sum and return its sum.
A subarray is a contiguous part of an array.
Example 1:
Input: nums = [-2,1,-3,4,-1,2,1,-5,4]
Output: 6
Explanation: [4,-1,2,1] has the largest sum = 6.
Example 2:
Input: nums = [1]
Output: 1
Example 3:
Input: nums = [5,4,-1,7,8]
Output: 23
说起来这个题其实非常有渊源,大学数据结构的第一个题就是这个,而最佳的算法就是传说中的 online 算法,就是遍历一次就完了,最基本的做法就是记下来所有的连续子数组,然后求出最大的那个。
public int maxSubArray(int[] nums) { |
给定一个二叉树,找出其最大深度。
二叉树的深度为根节点到最远叶子节点的最长路径上的节点数。
说明: 叶子节点是指没有子节点的节点。
示例:
给定二叉树 [3,9,20,null,null,15,7],
3 |
返回它的最大深度 3 。
// 主体是个递归的应用 |
其实对于树这类题,一般是以递归形式比较方便,只是要注意退出条件
]]>Given preorder and inorder traversal of a tree, construct the binary tree.
给定一棵树的前序和中序遍历,构造出一棵二叉树
You may assume that duplicates do not exist in the tree.
你可以假设树中没有重复的元素。(PS: 不然就没法做了呀)
preorder = [3,9,20,15,7] |
返回的二叉树
3 |
看到这个题可以想到一个比较常规的解法就是递归拆树,前序就是根左右,中序就是左根右,然后就是通过前序已经确定的根在中序中找到,然后去划分左右子树,这个例子里是 3,找到中序中的位置,那么就可以确定,9 是左子树,15,20,7是右子树,然后对应的可以根据左右子树的元素数量在前序中划分左右子树,再继续递归就行
class Solution { |
class FooBar { |
The same instance of FooBar will be passed to two different threads:
A will call foo(), whileB will call bar()."foobar" n times.Input: n = 1
Output: “foobar”
Explanation: There are two threads being fired asynchronously. One of them calls foo(), while the other calls bar().
“foobar” is being output 1 time.
Input: n = 2
Output: “foobarfoobar”
Explanation: “foobar” is being output 2 times.
其实用信号量是很直观的,就是让打印 foo 的线程先拥有信号量,打印后就等待,给 bar 信号量 + 1,然后 bar 线程运行打印消耗 bar 信号量,再给 foo 信号量 + 1
class FooBar { |
You are given an array prices where prices[i] is the price of a given stock on the ith day.
You want to maximize your profit by choosing a single day to buy one stock and choosing a different day in the future to sell that stock.
Return the maximum profit you can achieve from this transaction. If you cannot achieve any profit, return 0.
给定一个数组 prices ,它的第 i 个元素 prices[i] 表示一支给定股票第 i 天的价格。
你只能选择 某一天 买入这只股票,并选择在 未来的某一个不同的日子 卖出该股票。设计一个算法来计算你所能获取的最大利润。
返回你可以从这笔交易中获取的最大利润。如果你不能获取任何利润,返回 0 。
其实这个跟二叉树的最长路径和有点类似,需要找到整体的最大收益,但是在迭代过程中需要一个当前的值
int maxSofar = 0; |
一开始看到 easy 就觉得是很简单,就没有 maxSofar ,但是一提交就出现问题了
对于[2, 4, 1]这种就会变成 0,所以还是需要一个历史值来存放历史最大值,这题有点动态规划的意思
A path in a binary tree is a sequence of nodes where each pair of adjacent nodes in the sequence has an edge connecting them. A node can only appear in the sequence at most once. Note that the path does not need to pass through the root.
The path sum of a path is the sum of the node’s values in the path.
Given the root of a binary tree, return the maximum path sum of any path.
路径 被定义为一条从树中任意节点出发,沿父节点-子节点连接,达到任意节点的序列。该路径 至少包含一个 节点,且不一定经过根节点。
路径和 是路径中各节点值的总和。
给你一个二叉树的根节点 root ,返回其 最大路径和
其实这个题目会被误解成比较简单,左子树最大的,或者右子树最大的,或者两边加一下,仔细想想都不对,其实有可能是产生于左子树中,或者右子树中,这两个都是指跟左子树根还有右子树根没关系的,这么说感觉不太容易理解,画个图
可以看到图里,其实最长路径和是左边这个子树组成的,跟根节点还有右子树完全没关系,然后再想一种情况,如果是整棵树就是图中的左子树,那么这个最长路径和就是左子树加右子树加根节点了,所以不是我一开始想得那么简单,在代码实现中也需要一些技巧
int ansNew = Integer.MIN_VALUE; |
这里非常重要的就是 ansNew 是最后的一个结果,而对于 maxSumNew 这个函数的返回值其实是需要包含了一个连续结果,因为要返回继续去算路径和,所以返回的是 currentSum,最终结果是 ansNew
难得有个 100%,贴个图哈哈
Given a 2D grid of size m x n and an integer k. You need to shift the grid k times.
In one shift operation:
Element at grid[i][j] moves to grid[i][j + 1].
Element at grid[i][n - 1] moves to grid[i + 1][0].
Element at grid[m - 1][n - 1] moves to grid[0][0].
Return the 2D grid after applying shift operation k times.
Input: grid = [[1,2,3],[4,5,6],[7,8,9]], k = 1
Output: [[9,1,2],[3,4,5],[6,7,8]]
Input: grid = [[3,8,1,9],[19,7,2,5],[4,6,11,10],[12,0,21,13]], k = 4
Output: [[12,0,21,13],[3,8,1,9],[19,7,2,5],[4,6,11,10]]
Input: grid = [[1,2,3],[4,5,6],[7,8,9]], k = 9
Output: [[1,2,3],[4,5,6],[7,8,9]]
m == grid.lengthn == grid[i].length1 <= m <= 501 <= n <= 50-1000 <= grid[i][j] <= 10000 <= k <= 100这个题主要是矩阵或者说数组的操作,并且题目要返回的是个 List,所以也不用原地操作,只需要找对位置就可以了,k 是多少就相当于让这个二维数组头尾衔接移动 k 个元素
public List<List<Integer>> shiftGrid(int[][] grid, int k) { |

比较慢
Design a stack that supports push, pop, top, and retrieving the minimum element in constant time.
设计一个栈,支持压栈,出站,获取栈顶元素,通过常数级复杂度获取栈中的最小元素
Example 1:
Input |
其实现在大部分语言都自带类栈的数据结构,Java 也自带 stack 这个数据结构,所以这个题的主要难点的就是常数级的获取最小元素,最开始的想法是就一个栈外加一个记录最小值的变量就行了,但是仔细一想是不行的,因为随着元素被 pop 出去,这个最小值也可能需要梗着变化,就不太好判断了,所以后面是用了一个辅助栈。
class MinStack { |
Given an integer array nums of length n and an integer target, find three integers in nums such that the sum is closest to target.
Return the sum of the three integers.
You may assume that each input would have exactly one solution.
简单解释下就是之前是要三数之和等于目标值,现在是找到最接近的三数之和。
Input: nums = [-1,2,1,-4], target = 1
Output: 2
Explanation: The sum that is closest to the target is 2. (-1 + 2 + 1 = 2).
Input: nums = [0,0,0], target = 1
Output: 0
3 <= nums.length <= 1000-1000 <= nums[i] <= 1000-10^4 <= target <= 10^4这个题思路上来讲不难,也是用原来三数之和的方式去做,利用”双指针法”或者其它描述法,但是需要简化逻辑
public int threeSumClosest(int[] nums, int target) { |

写一个程序找出两个单向链表的交叉起始点,可能是我英语不好,图里画的其实还有一点是交叉以后所有节点都是相同的
Write a program to find the node at which the intersection of two singly linked lists begins.
For example, the following two linked lists:
begin to intersect at node c1.

Input: intersectVal = 8, listA = [4,1,8,4,5], listB = [5,6,1,8,4,5], skipA = 2, skipB = 3 |
一开始没什么头绪,感觉只能最原始的遍历,后来看了一些文章,发现比较简单的方式就是先找两个链表的长度差,因为从相交点开始肯定是长度一致的,这是个很好的解题突破口,找到长度差以后就是先跳过长链表的较长部分,然后开始同步遍历比较 A,B 链表;
public ListNode getIntersectionNode(ListNode headA, ListNode headB) { |
可能缺少这种思维,做的还是比较少,所以没法一下子反应过来,需要锻炼,我的第一反应是两重遍历,不过那样复杂度就高了,这里应该是只有 O(N) 的复杂度。
]]>You are given two non-empty linked lists representing two non-negative integers. The digits are stored in reverse order, and each of their nodes contains a single digit. Add the two numbers and return the sum as a linked list.
You may assume the two numbers do not contain any leading zero, except the number 0 itself.
就是给了两个链表,用来表示两个非负的整数,在链表中倒序放着,每个节点包含一位的数字,把他们加起来以后也按照原来的链表结构输出
Input: l1 = [2,4,3], l2 = [5,6,4] |
Input: l1 = [0], l2 = [0] |
Input: l1 = [9,9,9,9,9,9,9], l2 = [9,9,9,9] |
public ListNode addTwoNumbers(ListNode l1, ListNode l2) { |
这里唯二需要注意的就是两个点,一个是循环条件需要包含进位值还存在的情况,还有一个是最后一个节点,如果是空的了,就不要在 new 一个出来了,写的比较挫
]]>Given an integer array nums, return the sum of floor(nums[i] / nums[j]) for all pairs of indices 0 <= i, j < nums.length in the array. Since the answer may be too large, return it modulo 10^9 + 7.
The floor() function returns the integer part of the division.
对应中文
给你一个整数数组 nums ,请你返回所有下标对 0 <= i, j < nums.length 的 floor(nums[i] / nums[j]) 结果之和。由于答案可能会很大,请你返回答案对10^9 + 7 取余 的结果。
函数 floor() 返回输入数字的整数部分。
Input: nums = [2,5,9]
Output: 10
Explanation:
floor(2 / 5) = floor(2 / 9) = floor(5 / 9) = 0
floor(2 / 2) = floor(5 / 5) = floor(9 / 9) = 1
floor(5 / 2) = 2
floor(9 / 2) = 4
floor(9 / 5) = 1
We calculate the floor of the division for every pair of indices in the array then sum them up.
Input: nums = [7,7,7,7,7,7,7]
Output: 49
1 <= nums.length <= 10^51 <= nums[i] <= 10^5这题不愧是 hard,要不是看了讨论区的一个大神的解答感觉从头做得想好久,
主要是两点,对于任何一个在里面的数,随便举个例子是 k,最简单的就是循环所有数对 k 除一下,
这样效率会很低,那么对于 k 有什么规律呢,就是对于所有小于 k 的数,往下取整都是 0,所以不用考虑,
对于所有大于 k 的数我们可以分成一个个的区间,[k,2k-1),[2k,3k-1),[3k,4k-1)……对于这些区间的
除了 k 往下取整,每个区间内的都是一样的,所以可以简化为对于任意一个 k,我只要知道与k 相同的有多少个,然后比 k 大的各个区间各有多少个数就可以了
static final int MAXE5 = 100_000; |
贴出来大神的解析,解析

Given a string s containing just the characters '(', ')', '{', '}', '[' and ']', determine if the input string is valid.
An input string is valid if:
Input: s = “()”
Output: true
Input: s = “()[]{}”
Output: true
Input: s = “(]”
Output: false
1 <= s.length <= 10^4s consists of parentheses only '()[]{}'.easy题,并且看起来也是比较简单的,三种括号按对匹配,直接用栈来做,栈里面存的是括号的类型,如果是左括号,就放入栈中,如果是右括号,就把栈顶的元素弹出,如果弹出的元素不是左括号,就返回false,如果弹出的元素是左括号,就继续往下走,如果遍历完了,如果栈里面还有元素,就返回false,如果遍历完了,如果栈里面没有元素,就返回true
class Solution { |
Given a singly linked list, determine if it is a palindrome.
给定一个单向链表,判断是否是回文链表
Input: 1->2
Output: false
Input: 1->2->2->1
Output: true
Follow up:
Could you do it in O(n) time and O(1) space?
首先这是个单向链表,如果是双向的就可以一个从头到尾,一个从尾到头,显然那样就没啥意思了,然后想过要不找到中点,然后用一个栈,把前一半塞进栈里,但是这种其实也比较麻烦,比如长度是奇偶数,然后如何找到中点,这倒是可以借助于双指针,还是比较麻烦,再想一想,回文链表,就跟最开始的一样,链表只有单向的,我用个栈不就可以逆向了么,先把链表整个塞进栈里,然后在一个个 pop 出来跟链表从头开始比较,全对上了就是回文了
/** |
Given a binary tree, find the lowest common ancestor (LCA) of two given nodes in the tree.
According to the definition of LCA on Wikipedia: “The lowest common ancestor is defined between two nodes p and q as the lowest node in T that has both p and q as descendants (where we allow a node to be a descendant of itself).”
给定一个二叉树, 找到该树中两个指定节点的最近公共祖先。
百度百科中最近公共祖先的定义为:“对于有根树 T 的两个节点 p、q,最近公共祖先表示为一个节点 x,满足 x 是 p、q 的祖先且 x 的深度尽可能大(一个节点也可以是它自己的祖先)。”
public TreeNode lowestCommonAncestor(TreeNode root, TreeNode p, TreeNode q) { |
k is a positive integer and is less than or equal to the length of the linked list. If the number of nodes is not a multiple of k then left-out nodes in the end should remain as it is.
Given this linked list: 1->2->3->4->5
For k = 2, you should return: 2->1->4->3->5
For k = 3, you should return: 3->2->1->4->5
这个题也算是经典中的经典了,各种算法题中的保留曲目,可能不全一样,不过反正都是逆转,这个算是比较难度大的,普通的应该就是整个链表反转,或者只对一个链表中的 m 到 n 位做翻转,这里是 k 个一组做翻转,其实这道题比较难的点是两个,一个是想清楚怎么处理,一个是代码的处理
简单来看下
public ListNode reverseKGroup(ListNode head, int k) { |
而最后这种则代码会简单一些,但是需要一定的理解成本,比较重要的一点是我们加了个虚拟的头结点,第一步会先获取下链表的总长度,然后在内循环里处理转置,重点就是分四步,
也就是图里的,第一步先把 cur 的下一个节点设置成 next 的 next 节点,这里就是图里 A 连接到 C,第二步是把 next 的 next 节点设置成虚拟头的 next节点,第三步是把 pre 的next 节点设置成 next,第四步是 next 往后移动
cur.next = next.next; |

在备注下代码
You are a product manager and currently leading a team to develop a new product. Unfortunately, the latest version of your product fails the quality check. Since each version is developed based on the previous version, all the versions after a bad version are also bad.
Suppose you have n versions [1, 2, ..., n] and you want to find out the first bad one, which causes all the following ones to be bad.
You are given an API bool isBadVersion(version) which returns whether version is bad. Implement a function to find the first bad version. You should minimize the number of calls to the API.
Input: n = 5, bad = 4
Output: 4
Explanation:
call isBadVersion(3) -> false
call isBadVersion(5) -> true
call isBadVersion(4) -> true
Then 4 is the first bad version.
Input: n = 1, bad = 1
Output: 1
简单来说就是一个二分查找,但是这个问题其实处理起来还是需要搞清楚一些边界问题
public int firstBadVersion(int n) { |
往右移动示例
往左移动示例

Given a string s, find the length of the longest substring without repeating characters.
Input: s = "abcabcbb" |
Input: s = "bbbbb" |
Input: s = "pwwkew" |
Input: s = "" |
就是一个最长不重复的字符串长度,因为也是中等难度的题,不太需要特别复杂的思考,最基本的就是O(N*N)两重循环,不过显然不太好,万一超时间,还有一种就是线性复杂度的了,这个就是需要搞定一个思路,比如字符串时 abcdefgaqwrty,比如遍历到第二个a的时候其实不用再从头去遍历了,只要把前面那个a给排除掉,继续往下算就好了
class Solution { |
注释应该写的比较清楚了。
]]>123 |
一共有这么几种,不过举这个例子是为了更具体的发现规律,对于第一个数字相同的情况,比如123跟132,是132在后,发现规律没,递增序列是最小的,递减序列是最大的,因为2个数字 只有两种排列,扩展到3个数字,也可以把它拆分开,同样是第一个数字是1,后面两个数字就又回到了前面12序列的情况,
所以就可以把问题分成两部分来解决,首先从后往前找到递减序列
通过例子来讲
1 4 6 5 3 2 |
为什么要找到递减序列,因为递减序列已经是最大的了,要做调整要在这个之前调整,并且要找的是下一个序列,所以要是最接近的那个,否则我找到的可能就是下N个了,这个有点类似于数学里进位的意思,比如十九,九已经是个位里最大的了,找下一个比它大的只能是前面一位加一,但是加一以后需要九变到这一位的最小,也就是零。
对于上面的例子,递减序列就是6532,第一个非递减的是4,我要找下一个就是要比当前这个大,那我就去后面找比4大的,至于为什么能找到,因为这是递减序列边界之外的,说明肯定有比它大的,那要找哪个呢,要找比4大的数字里最小的,这样才是最近的下一个序列,并且因为后面是递减序列,所以可以直接从后往前找第一个
也就是会找到 5
找到 5 之后就做交换
1 5 6 4 3 2 |
这样是不是就行了呢,不行,因为这不是下一个,而是下N个,当4变成5之后,这个序列不管5后面的数字怎么变都是比 146532 大的,但是要找的是下一个,最接近的那个,则需要后面的序列变成最小,也就是变成递增序列,也就是
1 5 2 3 4 6 |
这里有两种例外情况,或者严格来说是一种
第一种是本身整个就是递减序列了,这在题中说了,下一个就是从头再开始,那就也很简单整个排序成递增的就行了
第二种是本身就是个完全递增的,那其实就交换末两位,但这种跟上面的可以糅合在一起,比如就是
1 2 3 4 5 6 |
单个6构不成递增或递减,找到的第一个非递减的数字就是 5 ,那就是在 5 后面找一个比它大的做交换,这时只有 6 ,所以就 5 跟 6 交换下,然后单个 5 做排序也等于不用做
再结合代码来看
public void nextPermutation(int[] nums) { |
给定两个数组 nums1 和 nums2 ,返回 它们的交集 。输出结果中的每个元素一定是 唯一 的。我们可以 不考虑输出结果的顺序 。
示例 1:
输入:nums1 = [1,2,2,1], nums2 = [2,2]
输出:[2]
示例 2:
输入:nums1 = [4,9,5], nums2 = [9,4,9,8,4]
输出:[9,4]
解释:[4,9] 也是可通过的
1 <= nums1.length, nums2.length <= 10000 <= nums1[i], nums2[i] <= 1000两个数组的交集,最简单就是两层循环了把两个都存在的找出来,不过还有个要去重的问题,稍微思考下可以使用集合 set 来处理,先把一个数组全丢进去,再对比另外一个,如果出现在第一个集合里就丢进一个新的集合,最后转换成数组,这次我稍微取了个巧,因为看到了提示里的条件,两个数组中的元素都是不大于 1000 的,所以就搞了个 1000 长度的数组,如果在第一个数组出现,就在对应的下标设置成 1,如果在第二个数组也出现了就加 1,
public int[] intersection(int[] nums1, int[] nums2) { |
给定两个大小分别为 m 和 n 的正序(从小到大)数组 nums1 和 nums2。请你找出并返回这两个正序数组的 中位数 。
算法的时间复杂度应该为 O(log (m+n)) 。
输入:nums1 = [1,3], nums2 = [2]
输出:2.00000
解释:合并数组 = [1,2,3] ,中位数 2
输入:nums1 = [1,2], nums2 = [3,4]
输出:2.50000
解释:合并数组 = [1,2,3,4] ,中位数 (2 + 3) / 2 = 2.5
这个题也是我随机出来的,之前都是随机到 easy 的,而且是序号这么靠前的,然后翻一下,之前应该是用 C++做过的,具体的方法其实可以从他的算法时间复杂度要求看出来,大概率是要二分法这种,后面就结合代码来讲了
public double findMedianSortedArrays(int[] nums1, int[] nums2) { |
前面考虑的方法还是比较繁琐,考虑了两个数组的各种交叉情况,后面这个参考了一些网上的解法,代码比较简洁,但是可能不容易一下子就搞明白,所以配合了比较多的注释。
]]>给定 n 个非负整数表示每个宽度为 1 的柱子的高度图,计算按此排列的柱子,下雨之后能接多少雨水。

输入:height = [0,1,0,2,1,0,1,3,2,1,2,1]
输出:6
解释:上面是由数组 [0,1,0,2,1,0,1,3,2,1,2,1] 表示的高度图,在这种情况下,可以接 6 个单位的雨水(蓝色部分表示雨水)。
其实最开始的想法是从左到右扫区间,就是示例中的第一个水槽跟第二个水槽都可以用这个办法解决
前面这种是属于右侧比左侧高的情况,对于左侧高右侧低的就不行了,(写这篇的时候想起来可以再反着扫一遍可能可以)
所以这个方案不好,贴一下这个方案的代码
public int trap(int[] height) { |
后面结合网上的解法,其实可以反过来,对于每个格子找左右侧的最大值,取小的那个和当前格子的差值就是这一个的储水量了
理解了这种想法,代码其实就不难了
int n = height.length; |
You are given an n x n 2D matrix representing an image, rotate the image by 90 degrees (clockwise).
You have to rotate the image in-place, which means you have to modify the input 2D matrix directly. DO NOT allocate another 2D matrix and do the rotation.
如图,这道题以前做过,其实一看有点蒙,好像规则很容易描述,但是代码很难写,因为要类似于贪吃蛇那样,后来想着应该会有一些特殊的技巧,比如翻转等
直接上码
public void rotate(int[][] matrix) { |
还没到可以直接归纳题目类型的水平,主要是几年前做过,可能有那么点模糊的记忆,当然应该也有直接转的方法
]]>Given the roots of two binary trees root and subRoot, return true if there is a subtree of root with the same structure and node values of subRoot and false otherwise.
A subtree of a binary tree tree is a tree that consists of a node in tree and all of this node’s descendants. The tree tree could also be considered as a subtree of itself.

Input: root = [3,4,5,1,2], subRoot = [4,1,2]
Output: true

Input: root = [3,4,5,1,2,null,null,null,null,0], subRoot = [4,1,2]
Output: false
需要判断subRoot 为根节点的这棵树是不是 root 为根节点的这个树的子树,题应该不是特别难理解,只是需要注意,这里是子树,而不是一个子结构,也就是示例 2 的判断结果是 false,因为左边子树还有个 0,只能认为是左边的一部分,但不是子树,思路分析也不难,就是递归去判断,只不过是两种维度,第一种就是找到子树的根节点,也就是在 root 树找到 subRoot 的根节点相同的节点,这个就会用到递归,如果找到了一个,就开始递归的对比所有子节点,必须完全一样
public boolean isSubtree(TreeNode root, TreeNode subRoot) { |
Given an integer array nums and an integer k, return true if it is possible to divide this array into k non-empty subsets whose sums are all equal.
Example 1:
Input: nums = [4,3,2,3,5,2,1], k = 4
Output: true
Explanation: It is possible to divide it into 4 subsets (5), (1, 4), (2,3), (2,3) with equal sums.
Example 2:
Input: nums = [1,2,3,4], k = 3
Output: false
Constraints:
看到这个题一开始以为挺简单,但是仔细想想问题还是挺多的,首先是分成 k 组,但是数量不限,应该需要用到回溯的方式,同时对于时间和空间复杂度也有要求,一开始这个代码是超时的,我也试了下 leetcode 上 discussion 里 vote 最高的提交也是超时的,不过看 discussion 里的帖子,貌似是后面加了一些条件,可以帮忙提高执行效率,第三条提示不太清楚意图,具体可以看下代码
public boolean canPartitionKSubsets(int[] nums, int k) { |
最后贴个图
You are given an integer array nums where the largest integer is unique.
Determine whether the largest element in the array is at least twice as much as every other number in the array. If it is, return the index of the largest element, or return -1 otherwise.
确认在数组中的最大数是否是其余任意数的两倍大及以上,如果是返回索引,如果不是返回-1
Input: nums = [3,6,1,0]
Output: 1
Explanation: 6 is the largest integer.
For every other number in the array x, 6 is at least twice as big as x.
The index of value 6 is 1, so we return 1.
Input: nums = [1,2,3,4]
Output: -1
Explanation: 4 is less than twice the value of 3, so we return -1.
2 <= nums.length <= 500 <= nums[i] <= 100nums is unique.这个题easy是题意也比较简单,找最大值,并且最大值是其他任意值的两倍及以上,其实就是找最大值跟次大值,比较下就好了
public int dominantIndex(int[] nums) { |
第一次错了是把第二大的情况只考虑第一种,也有可能最大值完全没经过替换就变成最大值了
给定一个已排序的链表的头 head , 删除所有重复的元素,使每个元素只出现一次 。返回 已排序的链表 。
PS:注意已排序,还有返回也要已排序

输入:head = [1,1,2]
输出:[1,2]

输入:head = [1,1,2,3,3]
输出:[1,2,3]
[0, 300] 内-100 <= Node.val <= 100这题其实是比较正常的 easy 级别的题目,链表已经排好序了,如果还带一个排序就更复杂一点,
只需要前后项做个对比,如果一致则移除后项,因为可能存在多个重复项,所以只有在前后项不同
时才会更新被比较项
public ListNode deleteDuplicates(ListNode head) { |
链表应该是个需要反复的训练的数据结构,因为涉及到前后指针,然后更新操作,判空等,
我在这块也是掌握的不太好,需要多练习。
You start at the cell (rStart, cStart) of an rows x cols grid facing east. The northwest corner is at the first row and column in the grid, and the southeast corner is at the last row and column.
You will walk in a clockwise spiral shape to visit every position in this grid. Whenever you move outside the grid’s boundary, we continue our walk outside the grid (but may return to the grid boundary later.). Eventually, we reach all rows * cols spaces of the grid.
Return an array of coordinates representing the positions of the grid in the order you visited them.
Input: rows = 1, cols = 4, rStart = 0, cStart = 0
Output: [[0,0],[0,1],[0,2],[0,3]]
Input: rows = 5, cols = 6, rStart = 1, cStart = 4
Output: [[1,4],[1,5],[2,5],[2,4],[2,3],[1,3],[0,3],[0,4],[0,5],[3,5],[3,4],[3,3],[3,2],[2,2],[1,2],[0,2],[4,5],[4,4],[4,3],[4,2],[4,1],[3,1],[2,1],[1,1],[0,1],[4,0],[3,0],[2,0],[1,0],[0,0]]
Constraints:
1 <= rows, cols <= 100 0 <= rStart < rows 0 <= cStart < cols这个题主要是要相同螺旋矩阵的转变方向的边界判断,已经相同步长会行进两次这个规律,写代码倒不复杂
public int[][] spiralMatrixIII(int rows, int cols, int rStart, int cStart) { |

Given a string, find the length of the longest substring without repeating characters.
For example, the longest substring without repeating letters for “abcabcbb” is “abc”,
which the length is 3. For “bbbbb” the longest substring is “b”, with the length of 1.
源码这次是参考了这个代码,
tail 表示的当前子串的起始点位置,tail从-1开始就包括的串的长度是1的边界。其实我
也是猜的(逃
int ct[256]; |
譬如
|
然后有挺多情况比如想要找日志里带一些符号什么的,就需要用到一些特殊的
比如这样\"userId\":\"123456\",因为比如用户 ID 有时候会跟其他的 id 一样,只用具体的值 123456 来查的话干扰信息太多了,如果直接这样
|
好像不行,盲猜就是符号的问题,特别是\和"这两个,
之前一直是想试一下,但是没成功,昨天在排查一个问题的时候发现了,只要把这些都转义了就行了
grep '\\\"userId\\\":\\\"123456\\\"' xxxx.log

void CTestDialog::OnBnClickedOk() |
模态对话框弹出确定后,在弹出对话框时新建的类及其变量会存在,但是对于其中的控件
对象无法调用函数,即如果要在主对话框中获得弹出对话框的Combo box选中值的话,需
要在弹出 对话框的确定函数内将其值取出,赋值给弹出对话框的公有变量,这样就可以
在主对话框类得到值。
Maven 是一个项目管理工具,可以对 Java 项目进行构建、依赖管理。
Maven 也可被用于构建和管理各种项目,例如 C#,Ruby,Scala 和其他语言编写的项目。Maven 曾是 Jakarta 项目的子项目,现为由 Apache 软件基金会主持的独立 Apache 项目。
maven也是我们日常项目中实用的包管理工具,相比以前需要用把包下载下来,放进 lib 中,在平时工作中使用的话,其实像 idea 这样的 ide 工具都会自带 maven 工具和插件
mvn -vmvn compilemvn testmvn packagemvn cleanmvn installmvn deploy因为我也是个 PHP 程序员,所以对比一下两种语言,很容易想到在 PHP 的 composer 跟 Java 的 maven 是比较类似的作用,有一点两者是非常相似的,就是原仓库都是因为某些原因连接拉取都会很慢,所以像 composer 会有一些国内源,前阵子阿里也出了一个,类似的 maven 一般也会使用阿里的镜像仓库,通过在 setting.xml 文件中的设置
<mirrors> |
这算是个尴尬的共同点,然后因为 PHP 是解释型脚本语言,所以 php 打出来的 composer 包其实就是个 php 代码包,使用SPL Autoload等方式加载代码包,maven 包则是经过编译的 class 包,还有一点是 composer 也可以直接使用 github 地址作为包代码的拉取源,这点也是比较大的区别,maven使用 pom 文件管理依赖
mvn compile加个-U参数,如果还不行就需要将本地仓库的 snapshot 删掉,mvn dependency:tree分析下依赖关系,如果要找具体某个包的依赖引用关系可以使用mvn dependency:tree -Dverbose -Dincludes=org.springframework:spring-webmvc命令进行分析,如果发现有冲突的依赖关系,本身 maven 中依赖引用有相对的顺序,大致来说是引用路径短的优先,pom 文件中定义的顺序优先,如果要把冲突的包排除掉可以在 pom 中用<exclusions> |
mvn -v可以查看 maven 的安装信息Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) |
java.lang.ExceptionInInitializerError: com.sun.tools.javac.code.TypeTags这个问题,所以需要把这个版本给改回来,但是咋改呢,网上搜来的一大堆都是在 pom 文件里的<build> |
<profiles> |
.mavenrc,这个顾名思义就是 maven 的资源文件,类似于 .bashrc和.zshrc,在里面添加 MAVEN_HOME 和 JAVA_HOME,然后执行 source .mavenrc就 OK 啦00000000000000000000000000001011, so the function should return 3.从1位到2位到4位逐步的交换
int hammingWeight(uint32_t n) { |
Given a binary tree and a sum, determine if the tree has a root-to-leaf path such that adding up all the values along the path equals the given sum.
For example:
Given the below binary tree and sum = 22,
5 |
return true, as there exist a root-to-leaf path 5->4->11->2 which sum is 22.
using simple deep first search
/* |
redis 分布式锁 redlock 的实现,简单记录下,
原先我对 redis 锁的概念就是加锁使用 setnx,解锁使用 lua 脚本,但是 setnx 具体是啥,lua 脚本是啥不是很清楚
首先简单思考下这个问题,首先为啥不是先 get 一下 key 存不存在,然后再 set 一个 key value,因为加锁这个操作我们是要保证两点,一个是不能中途被打断,也就是说要原子性,如果是先 get 一下 key,如果不存在再 set 值的话,那就不是原子操作了;第二个是可不可以直接 set 值呢,显然不行,锁要保证唯一性,有且只能有一个线程或者其他应用单位获得该锁,正好 setnx 给了我们这种原子命令
然后是 setnx 的键和值分别是啥,键比较容易想到是要锁住的资源,比如 user_id, 这里有个我自己之前比较容易陷进去的误区,但是这个误区后
面再说,这里其实是把user_id 作为要锁住的资源,在我获得锁的时候别的线程不允许操作,以此保证业务的正确性,不会被多个线程同时修改,确定了键,再来看看值是啥,其实原先我认为值是啥都没关系,我只要锁住了,光键就够我用了,但是考虑下多个线程的问题,如果我这个线程加了锁,然后我因为 gc 停顿等原因卡死了,这个时候redis 的锁或者说就是 redis 的缓存已经过期了,这时候另一个线程获得锁成功,然后我这个线程又活过来了,然后我就仍然认为我拿着锁,我去对数据进行修改或者释放锁,是不是就出现问题了,所以是不是我们还需要一个东西来区分这个锁是哪个线程加的,所以我们可以将值设置成为一个线程独有识别的值,至少在相对长的一段时间内不会重复。
上面其实还有两个问题,一个是当 gc 超时时,我这个线程如何知道我手里的锁已经过期了,一种方法是我在加好锁之后就维护一个超时时间,这里其实还有个问题,不过跟第二个问题相关,就一起说了,就是设置超时时间,有些对于不是锁的 redis 缓存操作可以是先设置好值,然后在设置过期时间,那么这就又有上面说到的不是原子性的问题,那么就需要在同一条指令里把超时时间也设置了,幸好 redis 提供了这种支持
SET resource_name my_random_value NX PX 30000 |
这里借鉴一下解释下,resource_name就是 key,代表要锁住的东西,my_random_value就是识别我这个线程的,NX代表只有在不存在的时候才设置,然后PX 30000表示超时时间是 30秒自动过期
PS:记录下我原先有的一个误区,是不是要用 key 来区分加锁的线程,这样只有一个用处,就是自身线程可以识别是否是自己加的锁,但是最大的问题是别的线程不知道,其实这个用户的出发点是我在担心前面提过的一个问题,就是当 gc 停顿后,我要去判断当前的这个锁是否是我加的,还有就是当释放锁的时候,如果保证不会错误释放了其他线程加的锁,但是这样附带很多其他问题,最大的就是其他线程怎么知道能不能加这个锁。
当线程在锁过期之前就处理完了业务逻辑,那就可以提前释放这个锁,那么提前释放要怎么操作,直接del key显然是不行的,因为这样就是我前面想用线程随机值加资源名作为锁的初衷,我不能去释放别的线程加的锁,那么我要怎么办呢,先 get 一下看是不是我的?那又变成非原子的操作了,幸好redis 也考虑到了这个问题,给了lua 脚本来操作这种
if redis.call("get",KEYS[1]) == ARGV[1] then |
这里的KEYS[1]就是前面加锁的resource_name,ARGV[1]就是线程的随机值my_random_value
前面说的其实是单节点 redis 作为分布式锁的情况,那么当我们的 redis 有多节点的情况呢,如果多节点下处于加锁或者解锁或者锁有效情况下redis 的某个节点宕掉了怎么办,这里就有一些需要思考的地方,是否单独搞一个单节点的 redis作为分布式锁专用的,但是如果这个单节点的挂了呢,还有就是成本问题,所以我们需要一个多节点的分布式锁方案
这里就引出了开头说到的redlock,这个可是 redis的作者写的, 他的加锁过程是分以下几步去做这个事情
Example1: x = 123, return 321
Example2: x = -123, return -321
Have you thought about this?
Here are some good questions to ask before coding. Bonus points for you if you have already thought through this!
If the integer’s last digit is 0, what should the output be? ie, cases such as 10, 100.
Did you notice that the reversed integer might overflow? Assume the input is a 32-bit integer, then the reverse of 1000000003 overflows. How should you handle such cases?
For the purpose of this problem, assume that your function returns 0 when the reversed integer overflows.
class Solution { |
For example, given input 43261596 (represented in binary as 00000010100101000001111010011100), return 964176192 (represented in binary as 00111001011110000010100101000000).
Follow up:
If this function is called many times, how would you optimize it?
class Solution { |
org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory#getWebServer
public WebServer getWebServer(ServletContextInitializer... initializers) { |
而 connector 中最重要的就是 ProtocolHandler ,初始化代码中org.apache.catalina.connector.Connector#Connector(java.lang.String)
public Connector(String protocol) { |
这里就调用了org.apache.coyote.ProtocolHandler#create
根据协议来生成对应的,我们这里默认就是org.apache.coyote.http11.Http11NioProtocol
public static ProtocolHandler create(String protocol, boolean apr) |
而这个初始化就主要做的是初始化 EndPoint
public Http11NioProtocol() { |
这个调用父类的方法是调用的org.apache.coyote.http11.AbstractHttp11Protocol#AbstractHttp11Protocol
public AbstractHttp11Protocol(AbstractEndpoint<S,?> endpoint) { |
而后在 Tomcat 启动后,在启动 connector 的时候
是在StandardService 添加 connector 时,启动了 connectororg.apache.catalina.core.StandardService#addConnector
|
而后就会调用到 Connector 的 initInternal 方法org.apache.catalina.connector.Connector#initInternal
|
这里继续往下走就是 protocolHandler 的 init 方法
|
看一下继承关系
然后就看到这里调用了 endpoint.init() ,走的也是父类的初始化方法,org.apache.tomcat.util.net.AbstractEndpoint#init
public final void init() throws Exception { |
然后接着调用了org.apache.tomcat.util.net.AbstractEndpoint#bindWithCleanup
private void bindWithCleanup() throws Exception { |
这里的 bind 方法调用的是org.apache.tomcat.util.net.NioEndpoint#bind
|
这里的 initServerSocket是后面抽出来的,方便扩展,主要就是开启 ServerSocketChannel,绑定端口
// Separated out to make it easier for folks that extend NioEndpoint to |
接着我们来看下 start 方法,这里多数是复用的 父类的方法org.apache.tomcat.util.net.AbstractEndpoint#start
public final void start() throws Exception { |
startInternal 才是 NioEndPoint 中的处理
/** |
上面是启动了一个 Poller 线程,在startAcceptorThread 里是启动了 acceptor
protected void startAcceptorThread() { |
启动后运行的代码
|
这行socket = endpoint.serverSocketAccept();是 accept 等待线程进来,进来以后调用
|
这里就是最重要的封装了 NioSocketWrapper, 然后注册到 Poller,
我们再来看 Poller 代码,注册其实是添加事件 event
public void register(final NioSocketWrapper socketWrapper) { |
然后Poller 的运行方法会处理这些 event
|
如果 events 方法返回了 true 代表有事件,就会跑到processKey(sk, socketWrapper); 来处理这个事件
而这里的 processKey 也比较复杂,
protected void processKey(SelectionKey sk, NioSocketWrapper socketWrapper) { |
正常请求回到这else if (!processSocket(socketWrapper, SocketEvent.OPEN_READ, true))
然后调用processSocket 进行处理,
public boolean processSocket(SocketWrapperBase<S> socketWrapper, |
这里就会调用 createSocketProcessor 进行处理了,不过这是下一篇的内容了。
this.webServer = factory.getWebServer(getSelfInitializer()); |
就会调用到之前说到的
private org.springframework.boot.web.servlet.ServletContextInitializer getSelfInitializer() { |
而这里有个org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext#getServletContextInitializerBeans
获取初始化所需要的 bean
protected Collection<ServletContextInitializer> getServletContextInitializerBeans() { |
里面就是 new 了这个 org.springframework.boot.web.servlet.ServletContextInitializerBeans#ServletContextInitializerBeans
public ServletContextInitializerBeans(ListableBeanFactory beanFactory, |
具体来看看 org.springframework.boot.web.servlet.ServletContextInitializerBeans#addAdaptableBeans
protected void addAdaptableBeans(ListableBeanFactory beanFactory) { |
里面是这两段逻辑,先从 beanfactory 里获取到该类型的 bean,然后包装成 RegistrationBean,添加到 initializers
protected <T> void addAsRegistrationBean(ListableBeanFactory beanFactory, Class<T> type, |
然后再回到第一段,其中的循环里面,因为 ServletContextInitializerBeans 继承了 AbstractCollection 并且实现了 iterator 接口
for (ServletContextInitializer beans : getServletContextInitializerBeans()) { |
在 for 循环中会把 Initializer 排序后的 sortedList 返回 iterator,也就是前面把 filter 包装成的 RegistrationBean
public Iterator<ServletContextInitializer> iterator() { |
然后调用了 onStartup 方法,
public final void onStartup(ServletContext servletContext) throws ServletException { |
就会去执行注册逻辑
]]>org.apache.tomcat.util.net.AbstractEndpoint#createSocketProcessor 从这里开始org.apache.tomcat.util.net.NioEndpoint#createSocketProcessor
|
里面实际的是 new 了
org.apache.tomcat.util.net.NioEndpoint.SocketProcessor#SocketProcessor
protected class SocketProcessor extends SocketProcessorBase<NioChannel> { |
然后是 org.apache.tomcat.util.net.NioEndpoint.SocketProcessor#doRun 这里开始运行
protected void doRun() { |
org.apache.coyote.AbstractProtocol.ConnectionHandler#process 这个 getHandler 是哪个呢
public AbstractHttp11Protocol(AbstractEndpoint<S,?> endpoint) { |
上面补充下这个 Handler,帮助后面的理解,而这个 connectionHandler 则是实现了 AbstractEndpoint.Handler
protected static class ConnectionHandler<S> implements AbstractEndpoint.Handler<S> { |
然后会继续寻找真实的 Processer
|
也就是 org.apache.coyote.http11.AbstractHttp11Protocol#createProcessor
|
再往后就是调用 process 方法了,然后它是 Http11Processor 的抽象父类org.apache.coyote.AbstractProcessorLight
会调用 org.apache.coyote.AbstractProcessorLight#process 来处理前面说的 socket
接着会跑到这
|
接下去就是org.apache.coyote.http11.Http11Processor#service
再就是调用coyote的 service 方法也就是 org.apache.catalina.connector.CoyoteAdapter#service
这里就会调用到
|
然后进行 valve 串的执行到 org.apache.catalina.core.StandardWrapperValve#invoke 中
会调用
filterChain.doFilter |
就会执行 filter 链
最后到org.apache.catalina.core.ApplicationFilterChain#internalDoFilter
servlet.service(request, response); |
就到了 DispatcherServlet 处理的流程, 这样就和之前介绍 DispatcherServlet开始的请求处理接上了。
]]><Server> |
参考这个 xml,而对于这些组件中,有一类有相同的基类,也就是这次要介绍的 ContainerBase,
包括 engine,host,context 还有 wrapper ,都是同样的容器组件,
而他们共同实现的接口就是 Container ,
主要包含了
public static final String ADD_CHILD_EVENT = "addChild"; |
这几个事件类型,
public Pipeline getPipeline(); |
包括 pipeline 和获取 parent,添加 child 跟查找 child,然后设置线程池的线程数等
而对于 ContainerBase
也包含了 Lifecycle 的常规方法
|
初始化方法主要就是之前讲过的线程池
后面就开始 startInternal
|
这里包括了 cluster 的启动和 realm 的启动,然后将 child 子组件添加到线程池里启动,然后循环 get 结果,接下去就是 pipeline 的启动,设置开始中状态,后面是 ContainerBackgroundProcessor 的启动
然后是停止方法
|
也是类似的,只不过停止顺序和刚才开始的顺序反了一下
]]><Server> |
上次我们讲解了 connector,也提到了初始化的流程,在org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory#getWebServer
代码中我们就能略窥一斑,
Tomcat tomcat = new Tomcat(); |
这里的 connector 是在 service 中的,而tomcat.getService().addConnector(connector); 这一行
具体来看下
public Service getService() { |
又调用了,org.apache.catalina.startup.Tomcat#getServer
public Server getServer() { |
可以看到,先 new 了 StandardServer,再 new 了 StandardService,可以理解为创建 Server 后具体是由 service 进行服务,
而在 service 中就是上面的配置文件里显示的,service 包含了 connector,可以是多个connector,负责接入,具体内容可以参看上一篇
而后是 Engine,Engine 的关系是一个 Service 有一个 Engine,Engine 负责处理真正的逻辑,
public Engine getEngine() { |
Engine 一般默认我们初始化的都是 StandardEngine,包括前面的 StandardServer 和StandardService,
而对于 host 来说,Engine 中可以包含多个 host,也就是可以处理多个虚拟主机的业务逻辑,
public Host getHost() { |
tomcat的特点也都是常规的懒加载,在 get 的第一次请求里进行初始化,这边同样创建了 StandardHost,对于可以有多个的 host,在 Engine 中添加也变成了addChild,而对于常规的 Tomcat 来说,往下一层就是 context 了,这个可以支持多个 web 应用,所以也是可以添加多个 context,但我这边以 springboot 嵌入的 Tomcat 举例,他是内嵌的 context
protected void prepareContext(Host host, ServletContextInitializer[] initializers) { |
是一个 TomcatEmbeddedContext,这一点比较特殊,希望这样会有个一个大致的概念。
|
这里先会获取线程数,
|
默认的 ContainerBase 的设置线程数是 1
private int startStopThreads = 1; |
那就会按照 org.apache.catalina.core.ContainerBase#reconfigureStartStopExecutor 来设置线程池类型
private void reconfigureStartStopExecutor(int threads) { |
此时线程池类型是 null 也就会走到上一个分支中,new 一个 InlineExecutorService 出来
前面的这些其实是在 StandardEngine 初始化过程中,也就是 initInternal 时候进行的
然后具体的使用是在 startInternal 开始方法中,
// Start our child containers, if any |
会获取当前 StandardEngine 的子组件提交给线程池进行启动
而这个 StartChild 也比较简单
private static class StartChild implements Callable<Void> { |
就是调用子组件的 start 方法,
在 org.apache.tomcat.util.threads.InlineExecutorService 的父类,java.util.concurrent.AbstractExecutorService 中先会把 Callable 包装成 FutureTask
public <T> Future<T> submit(Callable<T> task) { |
然后进行执行,
|
这个就是我们 startStopExecutor 的主要作用,帮我们启动子组件
对于 Container 来说启动的就是 host,而其实 host 也是继承了 ContainerBase 的,后面可以再继续介绍下
public interface Lifecycle { |
对应的就是 Lifecycle 的状态,可以在 LifecycleState 中看到,这个枚举有两个字段组成,available 表示该状态下这个对应的组件状态是否可用,另一个就是对应的事件,比如 INITIALIZING 这个 state 对应的 BEFORE_INIT_EVENT
public enum LifecycleState { |
然后可以看看 Lifecycle 的状态流转示意,下面是从 Lifecycle 的代码注释里拷出来的
Common interface for component life cycle methods. Catalina components may implement this interface (as well as the appropriate interface(s) for the functionality they support) in order to provide a consistent mechanism to start and stop the component. The valid state transitions for components that support Lifecycle are:
start() |
Any state can transition to FAILED.
Calling start() while a component is in states STARTING_PREP, STARTING or
STARTED has no effect.
Calling start() while a component is in state NEW will cause init() to be
called immediately after the start() method is entered.
Calling stop() while a component is in states STOPPING_PREP, STOPPING or
STOPPED has no effect.
Calling stop() while a component is in state NEW transitions the component
to STOPPED. This is typically encountered when a component fails to start and
does not start all its sub-components. When the component is stopped, it will
try to stop all sub-components - even those it didn’t start.
Attempting any other transition will throw LifecycleException.
The LifecycleEvents fired during state changes are defined in the methods that trigger the changed. No LifecycleEvents are fired if the attempted transition is not valid.
好的项目就是会把这样的示意图画得很好,把状态流转都画得很明确,而不一定要什么好看的作图工具,用字符就可以
而在 LifecycleBase类中是把更细节的实现了,
init方法就是先判断了状态
|
在判断状态后就先设置了初始化中这个状态,这里设置的时候是 check 是 false 的,所以直接到设置状态,并且触发事件
private synchronized void setStateInternal(LifecycleState state, Object data, boolean check) |
触发事件调用了 fireLifecycleEvent
protected void fireLifecycleEvent(String type, Object data) { |
会调用所有的 listener 将事件发送出去
而回到上面 init 方法,第二步的 initInternal 就是 Tomcat 的 Lifecycle 中非常核心的一点了
因为上面说到很多组件都是继承了 LifecycleBase 的,实际外部被调用的其实都是 LifecycleBase 的
init,start 等方法,内部是由这个抽象基类去设置前后的状态,以及调用 initInternal ,也就是具体
实现类的实现方法,譬如 connector 的 initInternal 方法,就是真正处理初始化逻辑的
|
start 方法也是类似的,但是更复杂,第一步也是状态判断,是不是已经被启动过了,如果还是 new 状态的话就先调用 init,如果已经 failed 启动失败了就直接调用 stop 结束了,如果是非已初始化和非已停止的状态则是错误的状态转变
如果是正常情况,那就是先设置成 STARTING_PREP,然后调用实现类的 startInternal,如果启动失败了就调用 stop,此时理论上应该是启动中 STARTING 状态,否则就是异常状态转变,剩下的就是状态启动完的状态,
|
stop 跟 destroy 也类似的
]]>org.apache.coyote.http11.Http11Processor#service
// Process the request in the adapter |
然后到 coyoteAdapter 的 serviceorg.apache.catalina.connector.CoyoteAdapter#service
try { |
主要先看到 postParseRequest
在 postParseRequest 的代码里会调用 Mapper 的 map 方法
while (mapRequired) { |
而后面的 context 就是在 map 方法里处理塞进去的
往里看就是 org.apache.catalina.mapper.Mapper#internalMap
第一步找的是 host
// Virtual host mapping |
而在后续代码里继续设置 context
if (contextVersion == null) { |
然后是 wrapper
// Wrapper mapping |
在这个方法 org.apache.catalina.mapper.Mapper#internalMapWrapper
// Rule 7 -- Default servlet |
这里就设置了 wrapper ,因为我们是在 Springboot 中,所以只有默认的 dispatchServlet
上面主要是在请求处理过程中的查找映射过程,一开始的注册是从 MapperListener 开始的
MapperListener 继承了 LifecycleMbeanBase,也就是有了 Lifecycle 状态变化那一套
|
在启动过程中就会去把 engine 的子容器 host 找出来进行注册,就是调用 registerHost 方法
private void registerHost(Host host) { |
在这里面会添加 host 组件,注册 context 等,注册context 里还会处理 wrapper 的添加记录
private void registerContext(Context context) { |
就是在 org.apache.catalina.mapper.Mapper#addContextVersion 方法中
public void addContextVersion(String hostName, Host host, String path, |
大致介绍了下 Mapper 的逻辑
]]>org.apache.catalina.core.ContainerBase.ContainerBackgroundProcessor
protected class ContainerBackgroundProcessor implements Runnable { |
这个触发方式是在 ContainerBase 里的
protected class ContainerBackgroundProcessorMonitor implements Runnable { |
而在这个 threadStart 里
protected void threadStart() { |
就调用了线程池的 scheduleWithFixedDelay 方法提交了这个 ContainerBackgroundProcessor,
仔细看代码会发现,
public StandardEngine() { |
这个就不用开启后台热加载,而主要的热加载同学应该是org.apache.catalina.core.StandardContext#backgroundProcess
public void backgroundProcess() { |
loader 的后台处理就是
|
然后又会回到 context 的 reload,也就是 StandardContext 的 reload
|
这样就是线程池结合后台处理,还是有些复杂的。
]]>org.apache.tomcat.util.http.fileupload.util.LimitedInputStream#checkLimit
private void checkLimit() throws IOException { |
其中的 raiseError 是个抽象方法
protected abstract void raiseError(long pSizeMax, long pCount) |
具体的实现是在
public FileItemStreamImpl(FileItemIteratorImpl pFileItemIterator, String pName, String pFieldName, String pContentType, boolean pFormField, long pContentLength) throws FileUploadException, IOException { |
后面也会介绍到,这里我们其实主要是要找到这个 pSizeMax 是哪里来的
通过阅读代码会发现跟这个类 MultipartConfigElement 有关系
而在升级后的 springboot 中这个类已经有了自动装配类,也就是org.springframework.boot.autoconfigure.web.servlet.MultipartAutoConfiguration
有了这个自动装配
|
而这个 MultipartProperties 类中
|
并且在前面 createMultipartConfig 中就使用了这个maxFileSize 的默认值
public MultipartConfigElement createMultipartConfig() { |
而在 org.apache.catalina.connector.Request#parseParts 中,会判断 mce 的配置
private void parseParts(boolean explicit) { |
主要 org.apache.tomcat.util.http.fileupload.FileUploadBase#parseRequest
public List<FileItem> parseRequest(final RequestContext ctx) |
其中 org.apache.tomcat.util.http.fileupload.FileUploadBase#getItemIterator
public FileItemIterator getItemIterator(final RequestContext ctx) |
这里就创建了 org.apache.tomcat.util.http.fileupload.impl.FileItemIteratorImpl
public FileItemIteratorImpl(final FileUploadBase fileUploadBase, final RequestContext requestContext) |
内部使用了前面给 upload 设置的文件大小上限 upload.setFileSizeMax(mce.getMaxFileSize());
然后在 findNextItem 里执行了初始化
private boolean findNextItem() throws FileUploadException, IOException { |
这里面就会 new 这个 FileItemStreamImpl
currentItem = new FileItemStreamImpl(this, fileName, |
构造方法比较长
public FileItemStreamImpl(final FileItemIteratorImpl pFileItemIterator, final String pName, final String pFieldName, |
当 fileSizeMax != 0 的时候就会初始化 LimitedInputStream,这就就是会在前面的
org.apache.tomcat.util.http.fileupload.FileUploadBase#parseRequest 中
Streams.copy(item.openStream(), fileItem.getOutputStream(), true, buffer); |
这里的 item
final FileItemIterator iter = getItemIterator(ctx); |
调用了 FileItemIterator 迭代器的 next
|
这个 currentItem 就是前面 new 的 FileItemStreamImpl
然后在 Streams.copy 的时候调用 openStream 也就是 org.apache.tomcat.util.http.fileupload.impl.FileItemStreamImpl#openStream
|
这里的 stream 就是 FileItemStreamImpl 构造方法最后赋值的 stream,会在大小超过限制时抛出错误
而这个可以通过设置 properties 来修改,spring.servlet.multipart.max-file-size 和 spring.servlet.multipart.max-request-size
spring.servlet.multipart.max-file-size=100MB |
而老版本的 spring.http.multipart.maxFileSize
其实就是配置名称改了下,但是能看一下代码也是有点收获的。
public void start() throws LifecycleException { |
getServer之前讲到过
public Server getServer() { |
会 new 一个StandardService,添加到 server 里,然后进行启动
而这个外面的 server.start 其实调用的是 org.apache.catalina.Lifecycle#start,
里面是一个 Lifecycle 的接口,这个接口被很多 Tomcat 的组件实现,其实都共用了 Lifecycle 的机制
然后 Lifecycle 里面会根据状态,调用实际的实现层的 startInternal 方法
|
这里会先设置状态,这个状态也有点东西,可以后面再讲,因为里面有个状态事件的触发
然后是启动 Engine,也就是 container,在这里就是 StandardEngine,先不深入去讲里面做了啥,后面讲 StandardEngine 的启动过程会讲,然后是启动线程池了,对于 StandardService 是没有线程池要启动的,或者是 springboot 集成的这个 Tomcat 中不需要,接着就是 mapperListener 的启动,这里其实是给 container 这种添加 listener,用来监听事件,做处理
然后就是启动 connector,connector 的启动就是之前说的,里面会启动 protocolHandler,这里还是一样的通过 Lifecycle 的接口,再通过 Lifecycle 的模板方法调用实际的 connector 实现 startInternal 方法,这也是 Tomcat 的一大特点,关于 Tomcat 也是个很大的课题,后面可能还会调整下组织结构,对新同学更友好一点。
值得注意的还有两个
第一个是添加 connector,先是锁一下,设置 connector 的 Service,然后 connectors 是个数组,这里进行了重新申请一个数组,然后进行拷贝,再把新添加的放到数组最后,
|
然后是判断当前的状态是否可用,如果可用就启动 connector, 最后触发下 connector 的变更事件
还有一个是设置Engine,
|
前面两步是把第一个的 engine 的 service 设置为 null,然后第二个 engine 也就是新的这个的 service 设置成当前的 service,然后也是判断状态,启动 engine,接着是重启 mapperListener,先关闭再启动,最后是关闭老的 engine,最后的最后就是触发 container 变更事件。
]]>connector.getService().getContainer().getPipeline().getFirst().invoke( |
这段代码是通过 CoyoteAdapter 将请求处理往 container 传,这里就有个 pipeline 机制,这个 pipeline 可以看一下接口
public interface Pipeline extends Contained { |
这里可以往 pipeline 里添加 valve,然后看下 valve 的接口
public interface Valve { |
这里主要看的就是 getNext 跟 setNext,就变成了一个有序的 pipeline,然后就是 invoke 方法,其实 pipeline 是由两部分组成,valve 在其中起到了前后衔接的重要作用,而且可以再 invoke 中进一步串联调用
图中我们可以看到,对于 container 这个 pipeline,是没设置 first 的,只有 basic,basic 就是个兜底的 valve,在 StandardPipeline 中的 getFirst 实现
|
取不到 first 就降级到 basic,也就是这里的 StandardEngineValve,
它的 invoke 我们来看下
|
比较简单,就是调用 host 中的 pipeline 里的第一个 valve 来处理
第一个是 org.apache.catalina.valves.ErrorReportValve,
这里处理的其实是先调用了 next
|
虽然是放在 first,实际是先调用 next 的 invoke,也就是 org.apache.catalina.core.StandardHostValve 的invoke 方法
|
这里的往下就是调用 context 的 pipeline 去处理请求了, StandardContext 的 pipeline 里的 first 是
org.apache.catalina.authenticator.NonLoginAuthenticator,处理认证相关的,然后 basic 就是
org.apache.catalina.core.StandardContextValve, 这里的来看下
|
会调用 wrapper 的 pipeline 去处理请求,这里也只有一个
org.apache.catalina.core.StandardWrapperValve
这部分的逻辑比较长,因为要串联后面的 filter 流程
|
这里就会创建 ApplicationFilterChain 然后进行filterChain.doFilter(request.getRequest(), response.getResponse());
doFilter 处理
Given an array of integers, find two numbers such that they add up to a specific target number.
The function twoSum should return indices of the two numbers such that they add up to the target, where index1 must be less than index2. Please note that your returned answers (both index1 and index2) are not zero-based.
You may assume that each input would have exactly one solution.
Input: numbers={2, 7, 11, 15}, target=9
Output: index1=1, index2=2
struct Node |
sort the array, then test from head and end, until catch the right answer
]]>ambari是一个大数据平台的管理工具,包含了hadoop, yarn, hive, hbase, spark等大数据的基础架构和工具,简化了数据平台的搭建,之前只是在同事搭建好平台后的一些使用,这次有机会从头开始用ambari来搭建一个测试的数据平台,过程中也踩到不少坑,简单记录下。
/etc/yum.repos.d/路径下,然后yum update && yum install ambari-server安装即可,如果有条件就用proxychains走下代理。ambari-server setup做一些初始化设置,其中包含了JDK路径的设置,数据库设置,设置好就OK了,然后执行ambari-server start启动服务,这里有个小插曲,因为ambari-server涉及到这么多服务,所以管理控制监控之类的模块是必不可少的,这部分可以在ambari-server的web ui界面安装,也可以命令行提前安装,这部分被称为HDF Management Pack,运行ambari-server install-mpack \ --mpack=http://public-repo-1.hortonworks.com/HDF/centos7/2.x/updates/2.1.4.0/tars/hdf_ambari_mp/hdf-ambari-mpack-2.1.4.0-5.tar.gz \ --purge \ --verboseambari-serverA binary watch has 4 LEDs on the top which represent the hours (0-11), and the 6 LEDs on the bottom represent the minutes (0-59).
Each LED represents a zero or one, with the least significant bit on the right.

For example, the above binary watch reads “3:25”.
Given a non-negative integer n which represents the number of LEDs that are currently on, return all possible times the watch could represent.
Input: n = 1 |
又是参(chao)考(xi)别人的代码,嗯,就是这么不要脸,链接
class Solution { |
resolv-file=/opt/homebrew/etc/dnsmasq.d/resolv.dnsmasq.conf |
结果发现 dnsmasq 就起不来了,因为是 brew 服务的形式起来,发现日志也没有, dnsmasq 配置文件本身也没什么日志,这个是最讨厌的,网上搜了一圈也都没有, brew services 的服务如果启动状态是 error,并且服务本身没有日志的话就是一头雾水,并且对于 plist 来说,即使我手动加了标准输出和错误输出,brew services restart 的时候也是会被重新覆盖,
后来仔细看了下这个问题,发现它下面有这么一行配置
conf-dir=/opt/homebrew/etc/dnsmasq.d/,*.conf |
想了一下发现这个问题其实很简单,dnsmasq 应该是不支持同一配置文件加载两次,
我把 resolv 文件放在了同一个配置文件目录下,所以就被加载了两次,所以改掉目录就行了,但是目前看 dnsmasq 还不符合我的要求,也有可能我还没完全了解 dnsmasq 的使用方法,我想要的是比如按特定的域名后缀来配置对应的 dns 服务器,这样就不太会被影响,可以试试 AdGuard 看
基于docker搭了个mysql集群,稍微记一下,
首先是新建mysql主库容
docker run -d -e MYSQL_ROOT_PASSWORD=admin --name mysql-master -p 3307:3306 mysql:latest-d表示容器运行在后台,-e表示设置环境变量,即MYSQL_ROOT_PASSWORD=admin,设置了mysql的root密码,--name表示容器名,-p表示端口映射,将内部mysql:3306映射为外部的3307,最后的mysql:latest表示镜像名
此外还可以用-v /local_path/my-master.cnf:/etc/mysql/my.cnf来映射配置文件
然后同理启动从库docker run -d -e MYSQL_ROOT_PASSWORD=admin --name mysql-slave -p 3308:3306 mysql:latest
然后进入主库改下配置文件docker-enter mysql-master如果无法进入就用docker ps -a看下容器是否在正常运行,如果status显示
未正常运行,则用docker logs mysql-master看下日志哪里出错了。
进入容器后,我这边使用的镜像的mysqld配置文件是在/etc/mysql下面,这个最新版本的mysql的配置文件包含
三部分,/etc/mysql/my.cnf和/etc/mysql/conf.d/mysql.cnf,还有/etc/mysql/mysql.conf.d/mysqld.cnf
这里需要改的是最后一个,加上
log-bin = mysql-bin |
保存后退出容器重启主库容器,然后进入从库更改相同文件,
log-bin = mysql-bin |
同样退出重启容器,然后是配置主从,首先进入主库,用命令mysql -u root -pxxxx进入mysql,然后赋予一个同步
权限GRANT REPLICATION SLAVE ON *.* to 'backup'@'%' identified by '123456';还是同样说明下,ON *.*表示了数
据库全部的权限,如果要指定数据库/表的话可以使用类似testDb/testTable,然后是'backup'@'%'表示给予同步
权限的用户名及其主机ip,%表示不限制ip,当然如果有防火墙的话还是会有限制的,最后的identified by '123456'
表示同步用户的密码,然后就查看下主库的状态信息show master status,如下图:![9G5FE[9%@7%G(B`Q7]E)5@R.png](https://ooo.0o0.ooo/2016/08/10/57aac43029559.png)
把file跟position记下来,然后再开一个terminal,进入从库容器,登陆mysql,然后设置主库
change master to |
通过docker-ip mysql-master可以查看容器的ip
这里有一点是要注意的,也是我踩的坑,就是如果是同一宿主机下两个mysql容器互联,我这里只能通过docker-ip和真实
的3306端口能够连接成功。
本文参考了这位同学的文章
docker最开始是之前在某位大佬的博客看到的,看上去有点神奇,感觉是一种轻量级的虚拟机,但是能做的事情好像差不多,那时候是在Ubuntu系统的vps里起一个Ubuntu的docker,然后在里面装个nginx,配置端口映射就可以访问了,后来也草草写过一篇使用docker搭建mysql集群,但是最近看了下好像是因为装docker的大佬做了一些别名还是什么操作,导致里面用的操作都不具有普遍性,而且主要是把搭的过程写了下,属于囫囵吞枣,没理解docker是干啥的,为啥用docker,就是操作了下,这几天借着搭phabricator的过程,把一些原来不理解,或者原来理解错误的地方重新理一下。
之前写的 mysql 集群,一主二备,这种架构在很多小型应用里都是这么配置的,而且一般是直接在三台 vps 里启动三个 mysql 实例,但是如果换成 docker 会有什么好处呢,其实就是方便部署,比如其中一台备库挂了,我要加一台,或者说备库的 qps 太高了,需要再加一个,如果要在 vps 上搭建的话,首先要买一台机器,等初始化,然后在上面修改源,更新,装 mysql ,然后配置主从,可能还要处理防火墙等等,如果把这些打包成一个 docker 镜像,并且放在自己的 docker registry,那就直接run 一下就可以了;还有比如在公司要给一个新同学整一套开发测试环境,以 Java 开发为例,要装 git,maven,jdk,配置 maven settings 和各种 rc,整合在一个镜像里的话,就会很方便了;再比如微服务的水平扩展。
但是为啥 docker 会有这种优势,听起来好像虚拟机也可以干这个事,但是虚拟机动辄上 G,而且需要 VMware,virtual box 等支持,不适合在Linux服务器环境使用,而且占用资源也会非常大。说得这么好,那么 docker 是啥呢
docker 主要使用 Linux 中已经存在的两种技术的一个整合升级,一个是 namespace,一个是cgroups,相比于虚拟机需要完整虚拟出一个操作系统运行基础,docker 基于宿主机内核,通过 namespace 和 cgroups 分隔进程,理念就是提供一个隔离的最小化运行依赖,这样子相对于虚拟机就有了巨大的便利性,具体的 namespace 和 cgroups 就先不展开讲,可以参考耗子叔的文章
那么我们先安装下 docker,参考官方的教程,安装,我的系统是 ubuntu 的,就贴了 ubuntu 的链接,用其他系统的可以找到对应的系统文档安装,安装完了的话看看 docker 的信息
sudo docker info |
输出以下信息
然后再来运行个 hello world 呗,
sudo docker run hello-world |
输出了这些
看看这个运行命令是怎么用的,一般都会看到这样子的,sudo docker run -it ubuntu bash, 前面的 docker run 反正就是运行一个容器的意思,-it是啥呢,还有这个什么 ubuntu bash,来看看docker run`的命令帮助信息
-i, --interactive Keep STDIN open even if not attached |
就是要有输入,我们运行的时候能输入
-t, --tty Allocate a pseudo-TTY |
要有个虚拟终端,
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...] |
上面说的-it 就是这里的 options,后面那个 ubuntu 就是 image 辣,image 是啥呢
Docker 把应用程序及其依赖,打包在 image 文件里面,可以把它理解成为类似于虚拟机的镜像或者运行一个进程的代码,跑起来了的叫docker 容器或者进程,比如我们将要运行的docker run -it ubuntu bash的ubuntu 就是个 ubuntu 容器的镜像,将这个镜像运行起来后,我们可以进入容器像使用 ubuntu 一样使用它,来看下我们的镜像,使用sudo docker image ls就能列出我们宿主机上的 docker 镜像了

一个 ubuntu 镜像才 64MB,非常小巧,然后是后面的bash,我通过交互式启动了一个 ubuntu 容器,然后在这个启动的容器里运行了 bash 命令,这样就可以在容器里玩一下了

只有刚才运行容器的 bash 进程和我刚执行的 ps,这里有个可以注意下的,bash 这个进程的 pid 是 1,其实这里就用到了 linux 中的PID Namespace,容器会隔离出一个 pid 的名字空间,这里面的进程跟外部的 pid 命名独立
sudo docker ps -a |

这个应该是比较常用的,因为比如是一个微服务容器,有时候就像看下运行状态,日志啥的
sudo docker exec -it [containerID] bash |

sudo docker logs [containerID] |
我在运行容器的终端里胡乱输入点啥,然后通过上面的命令就可以看到啦


上一篇的 Dockerfile 我们停留在构建阶段,现在来把它跑起来
docker run -d -p 80 --name static_web nicksxs/static_web \ |
这里的-d表示以分离模型运行docker (detached),然后-p 是表示将容器的 80 端口开放给宿主机,然后容器名就叫 static_web,使用了我们上次构建的 static_web 镜像,后面的是让 nginx 在前台运行
可以看到返回了个容器 id,但是具体情况没出现,也没连上去,那我们想看看怎么访问在 Dockerfile 里写的静态页面,我们来看下docker 进程
发现为我们随机分配了一个宿主机的端口,32768,去服务器的防火墙把这个外网端口开一下,看看是不是符合我们的预期呢
好像不太对额,应该是 ubuntu 安装的 nginx 的默认工作目录不对,我们来进容器看看,再熟悉下命令docker exec -it 4792455ca2ed /bin/bash
记得容器 id 换成自己的,进入容器后得找找 nginx 的配置文件,通常在/etc/nginx,/usr/local/etc等目录下,然后找到我们的目录是在这
所以把刚才的内容复制过去再试试
目标达成,give me five✌️
然后就想来动态一点的,毕竟写过 PHP,就来试试 PHP
再建一个目录叫 dynamic_web,里面创建 src 目录,放一个 index.php
内容是
|
然后在 dynamic_web 目录下创建 Dockerfile,
FROM trafex/alpine-nginx-php7:latest |
Dockerfile 虽然只有三行,不过要着重说明下,这个底包其实不是docker 官方的,有两点考虑,一点是官方的基本都是 php apache 的镜像,还有就是 alpine这个,截取一段中文介绍
Alpine 操作系统是一个面向安全的轻型 Linux 发行版。它不同于通常 Linux 发行版,Alpine 采用了 musl libc 和 busybox 以减小系统的体积和运行时资源消耗,但功能上比 busybox 又完善的多,因此得到开源社区越来越多的青睐。在保持瘦身的同时,Alpine 还提供了自己的包管理工具 apk,可以通过 https://pkgs.alpinelinux.org/packages 网站上查询包信息,也可以直接通过 apk 命令直接查询和安装各种软件。
Alpine 由非商业组织维护的,支持广泛场景的 Linux发行版,它特别为资深/重度Linux用户而优化,关注安全,性能和资源效能。Alpine 镜像可以适用于更多常用场景,并且是一个优秀的可以适用于生产的基础系统/环境。
Alpine Docker 镜像也继承了 Alpine Linux 发行版的这些优势。相比于其他 Docker 镜像,它的容量非常小,仅仅只有 5 MB 左右(对比 Ubuntu 系列镜像接近 200 MB),且拥有非常友好的包管理机制。官方镜像来自 docker-alpine 项目。
目前 Docker 官方已开始推荐使用 Alpine 替代之前的 Ubuntu 做为基础镜像环境。这样会带来多个好处。包括镜像下载速度加快,镜像安全性提高,主机之间的切换更方便,占用更少磁盘空间等。
一方面在没有镜像的情况下,拉取 docker 镜像还是比较费力的,第二个就是也能节省硬盘空间,所以目前有大部分的 docker 镜像都将 alpine 作为基础镜像了
然后再来构建下
这里还有个点,就是上面的那个镜像我们也是 EXPOSE 80端口,然后外部宿主机会随机映射一个端口,为了偷个懒,我们就直接指定外部端口了docker run -d -p 80:80 dynamic_web打开浏览器发现访问不了,咋回事呢
因为我们没看trafex/alpine-nginx-php7:latest这个镜像说明,它内部的服务是 8080 端口的,所以我们映射的暴露端口应该是 8080,再用 docker run -d -p 80:8080 dynamic_web这个启动,
这里我们开始玩一点有意思的,我们在容器里装下 vim 和 gcc,然后写这样一段 c 代码
|
就是一个最简单的死循环,然后在容器里跑起来
gcc 1.c |
然后我们来看下系统资源占用(CPU)
上图是在容器里的,可以看到 cpu 已经 100%了
然后看看容器外面的
可以看到一个核的 cpu 也被占满了,因为是个双核的机器,并且代码是单线程的
然后呢我们要做点啥
因为已经在这个 ubuntu 容器中装了 vim 和 gcc,考虑到国内的网络,所以我们先把这个容器 commit 一下,
docker commit -a "nick" -m "my ubuntu" f63c5607df06 my_ubuntu:v1 |
然后再运行起来
docker run -it --cpus=0.1 my_ubuntu:v1 bash |

我们的代码跟可执行文件都还在,要的就是这个效果,然后再运行一下
结果是这个样子的,有点神奇是不,关键就在于 run 的时候的--cpus=0.1这个参数,它其实就是基于我前一篇说的 cgroup 技术,能将进程之间的cpu,内存等资源进行隔离
上一面为了复用那个我装了 vim 跟 gcc 的容器,我把它提交到了本地,使用了docker commit命令,有点类似于 git 的 commit,但是这个不是个很好的操作方式,需要手动介入,这里更推荐使用 Dockerfile 来构建镜像
From ubuntu:latest |
先解释下这是在干嘛,首先是这个From ubuntu:latest基于的 ubuntu 的最新版本的镜像,然后第二行是维护人的信息,第三四行么作为墙内人你懂的,把 ubuntu 的源换成阿里云的,不然就有的等了,然后就是装下 nginx,往默认的 nginx 的入口 html 文件里输入一行欢迎语,然后暴露 80 端口
然后我们使用sudo docker build -t="nicksxs/static_web" .命令来基于这个 Dockerfile 构建我们自己的镜像,过程中是这样的

可以看到图中,我的 Dockerfile 是 7 行,里面就执行了 7 步,并且每一步都有一个类似于容器 id 的层 id 出来,这里就是一个比较重要的东西,docker 在构建的时候其实是有这个层的概念,Dockerfile 里的每一行都会往上加一层,这里有还注意下命令后面的.,代表当前目录下会自行去寻找 Dockerfile 进行构建,构建完了之后我们再看下我们的本地镜像
我们自己的镜像出现啦
然后有个问题,如果这个构建中途报了错咋办呢,来试试看,我们把 nginx 改成随便的一个错误名,nginxx(不知道会不会运气好真的有这玩意),再来 build 一把
找不到 nginxx 包,是不是这个镜像就完全不能用呢,当然也不是,因为前面说到了,docker 是基于层去构建的,可以看到前面的 4 个 step 都没报错,那我们基于最后的成功步骤创建下容器看看
也就是sudo docker run -t -i bd26f991b6c8 /bin/bash
答案是可以的,只是没装成功 nginx
还有一点注意到没,前面的几个 step 都有一句 Using cache,说明 docker 在构建镜像的时候是有缓存的,这也更能说明 docker 是基于层去构建镜像,同样的底包,同样的步骤,这些层是可以被复用的,这就是 docker 的构建缓存,当然我们也可以在 build 的时候加上--no-cache去把构建缓存禁用掉。
!/bin/bash |
直接执行的话就是单核100%的cpu
首先在cgroup下面建个目录
mkdir -p /sys/fs/cgroup/cpu/sxs_test/ |
查看目录下的文件
其中cpuacct开头的表示cpu相关的统计信息,
我们要配置cpu的额度,是在cpu.cfs_quota_us中
echo 2000 > /sys/fs/cgroup/cpu/sxs_test/cpu.cfs_quota_us |
这样表示可以使用2%的cpu,总的配额是在cpu.cfs_period_us中
然后将当前进程输入到cgroup.procs,
echo $$ > /sys/fs/cgroup/cpu/sxs_test/cgroup.procs |
这样就会自动继承当前进程产生的新进程
再次执行就可以看到cpu被限制了
<dependency> |
有个别应用用的是这个
<dependency> |
还有的应用是找不到相关的依赖,并且这些的使用没有个比较好的说明,为啥用前者,为啥用后者,有啥注意点,
首先在使用 2.6.5 的 alibaba 的 dubbo 的时候,只使用后者是会报错的,至于为啥会报错,其实就是这篇文章想说明的点
报错的内容其实很简单, 就是缺少这个 org.apache.curator.framework.CuratorFrameworkFactory 类
这个类看着像是依赖上面的配置,但是应该不需要两个配置一块用的,所以还是需要去看代码
通过找上面类被依赖的和 dubbo 连接注册中心相关的代码,看到了这段指点迷津的代码
|
众所周知,dubbo 创造了叫自适应扩展点加载的神奇技术,这里的 adaptive 注解中的Constants.CLIENT_KEY 和 Constants.TRANSPORTER_KEY 可以在配置 dubbo 的注册信息的时候进行配置,如果是通过 xml 配置的话,可以在 <dubbo:registry/> 这个 tag 中的以上两个 key 进行配置,
具体在 dubbo.xsd 中有描述
<xsd:element name="registry" type="registryType"> |

并且在 spi 的配置com.alibaba.dubbo.remoting.zookeeper.ZookeeperTransporter 中可以看到
zkclient=com.alibaba.dubbo.remoting.zookeeper.zkclient.ZkclientZookeeperTransporter |
而在上面的代码里默认的SPI 值是 curator,所以如果不配置,那就会报上面找不到类的问题,所以如果需要使用 zkclient 的,就需要在<dubbo:registry/> 配置中添加 client="zkclient"这个配置,所以有些地方还是需要懂一些更深层次的原理,但也不至于每个东西都要抠到每一行代码原理,除非就是专门做这一块的。
还有一点是发现有些应用是碰运气,刚好有个三方包把这个类带进来了,但是这个应用就没有单独配置这块,如果不了解或者后续忘了再来查问题就会很奇怪
最近做 docker 系列,会经常需要进到 docker 内部,如上一篇介绍的,这些镜像一般都有用 ubuntu 或者alpine 这样的 Linux 系统作为底包,如果构建镜像的时候没有替换源的话,因为特殊的网络原因,在内部想编辑下东西要安装个类似于 vim 这样的编辑器就会很慢很慢,像视频里 two thousand years later~ 而且如果在容器内部想改源配置的话也要编辑器,就陷入了一个鸡生蛋,跟蛋生鸡的死锁问题中,对于 linux 大神来说应该有一万种方法解决这个问题,对于我这个渣渣来说可能只想到了这个土方法,先 cp backup 一下 sources.list, 再 echo “xxx” > sources.list, 这里就碰到了一个问题,这个 sources.list 一般不止一行,直接 echo 的话就解析不了了,不过 echo 可以支持”\n”转义,就是加-e看一下解释和示例,我这里使用了 tldr ,可以用 npm install -g tldr 安装,也可以直接用man, 或者–help 来查看使用方式
还有一点也是在这个时候要安装 vim 之类的,得知道是什么镜像底包,如果是用 uname 指令,其实看到的是宿主机的系统,得用cat /etc/issue

这里稍稍记一下
目前国内系统源用得比较多的是阿里云源,不过这里也推荐清华源, 中科大源, 浙大源 这里不要脸的推荐下母校的源,不过还不是很完善,尽情期待下。
]]>WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! |
错误信息是这样,有点奇怪也没干啥,网上一搜发现是We updated our RSA SSH host key
简单翻一下就是
在3月24日协调世界时大约05:00时,出于谨慎,我们更换了用于保护 GitHub.com 的 Git 操作的 RSA SSH 主机密钥。我们这样做是为了保护我们的用户免受任何对手模仿 GitHub 或通过 SSH 窃听他们的 Git 操作的机会。此密钥不授予对 GitHub 基础设施或客户数据的访问权限。此更改仅影响通过使用 RSA 的 SSH 进行的 Git 操作。GitHub.com 和 HTTPS Git 操作的网络流量不受影响。
要解决也比较简单就是重置下 host key,
Host Key是服务器用来证明自己身份的一个永久性的非对称密钥
使用
ssh-keygen -R github.com |
然后在首次建立连接的时候同意下就可以了
]]>git stash 跟 git commit 的小技巧,这次来讲下另一个命令,git cherry-pick,我怀疑这个命令应该叫 choose-pick 才比较好commit idgit cherry-pick {commit id}git stash命令就能很好的解决这个问题,但是这里在使用git stash的时候我认为有两个阶段git add 1.txt |
添加到暂存区,但不提交,然后使用
git stash |
保存工作进度,git stash之后再用 git status 就看不到刚才的更改了
然后就是弹出刚才stash的变更了
可以使用 git stash pop 就可以把刚才藏起来的临时变更就弹出来了
这里其实在真正使用时我们如果是深度使用就可能会出现四个问题或者是诉求
我不止stash了一次变更,怎么找到stash的多少次呢,因为直接用 pop 就是把栈顶的那次隐藏的变更弹出来了
这个问题就可以通过 git stash list 来解决
如果使用的pop我们这个stash相当于栈顶弹出,已经pop出来的就没有了,如果我只是想看一下改了哪些,当然我们可以先pop出来,在stash回去,
但更好的办法就是用git stash apply,这样是不会清栈的
如何指定弹出,比如我在list里能看到多次stash,那么我想弹出其中某一次
可以用git stash pop stash@{1} 注意这个 stash@{1} 是指stash list 的第二个,因为是从0开始的
弹出倒数第二次stash的
我想知道我这个stash里内容是啥,在不用pop和apply的情况下有没有办法
也是有的
可以使用 git stash show 1 或者 git stash show stash@{1} 来查看这次变更了哪些文件
甚至我们可以用 git stash show 1 -p 来查看具体变更的内容
git stash我觉得是个非常有用的功能,简直是个大杀器,除非不存在需要切换分支的场景,否则在频繁切换的时候,git stash 可以让我们的commit更清晰,不至于写到一半就提交,频繁切换,甚至连commit信息都写不好commit都会提交我们的变更,然后我们可以通过git diff .查看当前仓库产生的未提交的变更,如果我想看某一次commit的变更呢,这个功能通过 git 的各种 gui 工具可以很方便的查看,如果通过命令其实也很方便,我们每一次的commit 都会产生一个 commit id , 看过我上一篇的可以联想到,是否 git commit 也有这种 show 命令,答案是肯定的,git log 来查看我们的提交记录commit idgit show xxxxx 来查看我们这次 commit 修改的内容, xxxxx 表示我们的 commit idgit show xxxxx 后面跟上文件名git show xxxxx 1.txtcommit 对 1.txt 这个文件的更改,都是比较简单入门的 git 命令的小延伸,只是觉得对我有点帮助就分享下
]]>webhook 的配置,需要的两个文件,一个是 hooks.json,这个是 webhook 服务的配置文件,像这样
[ |
这是个跟 github搭配的示例,首先 id 表示的是这个对应 hook 的识别 id,也可以看到这个 hooks.json 的结构是这样的一个数组,然后就是要执行的命令和命令执行的参数,值得注意的是这个trigger-rule,就是请求进来了回去匹配里面的,比如前一个是一个加密的,放在请求头里,第二个 match 表示请求里的 ref 是个 master 分支,就可以区分分支进行不同操作,但是前面的加密配合 gogs 使用的时候有个问题(PS: webhook 的文档是真的烂),gogs 设置 webhook 的加密是用的
密钥文本将被用于计算推送内容的 SHA256 HMAC 哈希值,并设置为
X-Gogs-Signature请求头的值。
这种加密方式,所以 webhook 的这个示例的加密方式不行,但这货的文档里居然没有说明支持哪些加密,神TM,后来还是翻 issue 翻到了, 需要使用这个payload-hash-sha256
脚本类似于这样
!/bin/bash -e |
就是简单的拉代码,然后构建下,真实使用时可能不是这样,因为页面会部署在 nginx 的作用目录,还需要 rsync 过去,这部分可能还涉及到两个问题第一个是使用 rsync 还是其他的 cp,不过这个无所谓;第二个是目录权限的问题,以我的系统ubuntu 为例,默认用户是 ubuntu,nginx 部署的目录是 www,所以需要切换用户等操作,一开始是想用在shell 文件中直接写了密码,但是不知道咋传,查了下是类似于这样 echo "passwd" | sudo -S cmd,通过管道命令往后传,然后就是这个-S, 参数的解释是-S, --stdin read password from standard input,但是这样么也不是太安全的赶脚,又看了下还有两种方法,
就是给root 设置一个不需要密码的命令类似于这样,
myusername ALL = (ALL) ALL |
另一种就是把默认用户跟 root 设置成同一个 group 的
真正实操的时候其实还有不少问题,首先运行 webhook 就碰到了我前面说的,使用 snap 运行的时候会找不到前面的 hooks.json配置文件,执行snap run webhook -hooks /opt/hooks/hooks.json -verbose就碰到下面的couldn't load hooks from file! open /opt/hooks/hooks.json: no such file or directory,后来直接下了个官方最新的 release,就直接执行 webhook -hooks /opt/hooks/hooks.json -verbose 就可以了,然后是前面的示例配置文件里的几个参数,比如head_commit.message 其实 gogs 推过来的根本没这玩意,而且都是数组,不知道咋取,烂文档,不过总比搭个 drone 好一点就忍了。补充一点就是在 debug 的时候需要看下问题出在哪,看看脚本有没有执行,所以需要在前面的 json 里加这个参数"include-command-output-in-response": true, 就能输出来脚本执行结果
grep -B 4 |
是匹配行的前4行,可以用before来记
grep -A 4 |
是匹配行的后4行,可以用after来记
然后
grep -C 4 |
是看匹配行的前后4行
而这次的主角是小写的c
grep -c 'something' filename.txt |

类似于这个效果,这又是个可以少打几个字符的偷懒技巧
grep -a 或者 grep --text
|
然后我们就有了 output.bin 这个二进制文件
本身 input.txt 的内容也很简单
12345 |
我们尝试用 grep 查找其中的内容,
就会出现这个问题
当我们加上了 -a 或者 --text 就是指定 grep 需要在包含二进制文件格式中或者将文件当做是文本文件来识别匹配
添加节点非常简单,比如 app store 或者官网可以下载 mac 的安装包,
安装包直接下载可以在这里,下载安装完后还需要做一些处理,才能让 Tailscale 使用 Headscale 作为控制服务器。当然,Headscale 已经给我们提供了详细的操作步骤,你只需要在浏览器中打开 URL:http://<HEADSCALE_PUB_IP>:<HEADSCALE_PUB_PORT>/apple,记得端口替换成自己的,就会看到这样的说明页

然后对于像我这样自己下载的客户端安装包,也就是standalone client,就可以用下面的命令
defaults write io.tailscale.ipn.macsys ControlURL http://<HEADSCALE_PUB_IP>:<HEADSCALE_PUB_PORT> 类似于 Windows 客户端需要写入注册表,就是把控制端的地址改成了我们自己搭建的 headscale 的,设置完以后就打开 tailscale 客户端右键点击 login,就会弹出一个浏览器地址

按照这个里面的命令去 headscale 的机器上执行,注意要替换 namespace,对于最新的 headscale 已经把 namespace 废弃改成 user 了,这点要注意了,其他客户端也同理,现在还有个好消息,安卓和 iOS 客户端也已经都可以用了,后面可以在介绍下局域网怎么部分打通和自建 derper。
]]>High-privilege API key, 后面有用cd hexo-site |
然后在 hexo 站点配置中添加
algolia: |
包括应用 Id,只搜索的 api key(默认给创建好的那个),indexName 就是最开始创建的 index 名,
export HEXO_ALGOLIA_INDEXING_KEY=High-privilege API key # Use Git Bash |
然后再到 next 配置中开启 algolia_search
Algolia Search |
搜索的界面其实跟 local 的差不多,就是搜索效果会好一些
也推荐可以搜搜过往的内容,已经左边有个热度的,做了个按阅读量排序的榜单。
4
/ \
2 7
/ \ / \
1 3 6 9
to
4
/ \
7 2
/ \ / \
9 6 3 1
Trivia:
This problem was inspired by this original tweet by Max Howell:
Google: 90% of our engineers use the software you wrote (Homebrew),
but you can’t invert a binary tree on a whiteboard so fuck off.
/** |
No appropriate protocol (protocol is disabled or cipher suites are inappropriate)java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security 路径下的 java.security 中jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, createSocketFactory 的时候使用了 TLSv1 这个证书协议
SSLContext sslContext = SSLContext.getInstance("TLS"); |
所以就有两种方案,一个是使用更新版本的 TLS 或者另一个就是使用比较久的 jdk,这也说明其实即使都是 jdk8 的,不同的小版本差异还是会有些影响,有的时候对于这些错误还是需要更深入地学习,不能一概而之认为就是 jdk 用的是 oracle 还是 openjdk 的,不同的错误可能就需要仔细确认原因所在。
]]>public class Demo { |
比如这样,有一个前提,就是这个列表其实是有序的,只是为了防止万一
所以对这个列表进行了排序,就直接使用了ArrayList自带的sort方法,由于是不小心用在了多线程环境
就有出现了一个并发变更报错
也就是这个异常 java.util.ConcurrentModificationException#ConcurrentModificationException()
看下注释
This exception may be thrown by methods that have detected concurrent modification of an object when such modification is not permissible. |
一般情况就是并发环境下进行了变更,
只是这里比较特殊,这个列表没有进行增删,同时是有序的,理论上应该是不会出现变更才对
但是它的确出现了,就得看下这个产生的原因
主要还是来看下这个java.util.ArrayList#sort的实现跟这个异常的抛出原理
public void sort(Comparator<? super E> c) { |
可以看到在排序前会有个 modCount 的赋值,如果在进行排序后,这个初始的 modCount 跟当前的不等的话就会抛出这个异常
那么什么时候会出现这两者不相等呢
简单推演下这个并发排序下的情况,线程1和线程2同时进入这个方法,拿到了一样的 modCount , 然后进行排序,第一个线程比较快,sort玩之后发现两者相等
就到了 modCount++ , 这时候第二个线程刚排序完,发现 modCount 已经比 expectedModCount 大了
这个时候就出现了这个异常的抛出时机
如果这么理解这个异常的确是应该会出现
而不是我们理解的,如果不变更元素,不调整顺序,就不会触发这个并发变更的异常
还是有很多值得学习的点
open tracing 的应用间调用路径,而是应用内部,举个例子,我有一个底层方法,比如DAO层的一个方法,有很多调用方,那么有什么方法,第一种是最简单,但是比较麻烦,我去每个调用方那打个日志,然后分析下日志,这个办法肯定是没错的,只是如果我的调用方很多,可能需要加日志的地方就很多了,会比较麻烦php中也讲到过这个,那时候也是帮助理清调用逻辑和调用来源,public class StackTrace { |
这个方法其实也比较简单
public StackTraceElement[] getStackTrace() { |
这里面返回的 StackTraceElement 的内容
public final class StackTraceElement implements java.io.Serializable { |
分别是定义的类,方法名,文件名,以及代码行数
我们就能看到这样的结果
java.lang.Thread.getStackTrace(Thread.java:1564) |
因为是栈,所以就是最上面的是最近的方法,而第二行其实是我的目标方法,就是前面描述的逻辑其实应该找到第3个元素,因为第1个是调用 getStackTrace 方法,
第2个是目标方法,第3个才是我们想要找的调用方方法,以及所在的行数
public class Main { |
然后有个Demo类
public class Demo { |
然后我们想要像切面一样在start方法前后织入一些前后置的逻辑
我们需要将一个maven的module
然后agent代码是这样, premain 方法会在我们指定挂载agent执行,并且就是入口方法
public class DemoAgent { |
然后这个 transformer 就是我要怎么在目标类里如何织入代码的逻辑
public class DemoTransformer implements ClassFileTransformer { |
接下去要在pom.xml里配置如何打包agent的命令
<build> |
需要指定 Premain-Class 来指定入口方法所在的类
然后用 mvn package 进行打包
打包后在我们的目标代码的启动vm参数里加上
-javaagent:/{path}/demo-agent-1.0-SNAPSHOT.jar |
{path} 需要替换成agent的jar包所在路径
然后执行目标main方法
就可以看到结果了,这样我们第一个agent的demo就跑起来了
%d可以作为整型的占位符,%s可以作为字符串的占位符,但是吧有的时候常用归常用,有的时候碰到问题了还是得学习记录下public class Demo { |
就是希望输出 “成功是99%的努力和1%的天赋” ,先不管这句话的正确性,看看能不能正常输出(肯定是不能)
Exception in thread "main" java.util.UnknownFormatConversionException: Conversion = '的' |
会有这样的报错,虽然是个小问题我们还是来仔细研究下,
首先这边format函数会根据可能的占位符去提取并分割字符串
private static final String formatSpecifier |
比如上面的字符串,可以提取到两个有效的 %d
然后对剩余的进行分割,分割后再遍历校验每一个字符
如果碰到单独的 % 就说明出现了错误的分隔符
会调用 checkText 来识别报错
而如果我们想要能够正常输出% 也非常简单,只需要使用两个百分号 %%
这里其实就是匹配到了上面 formatSpecifier 的最后面,%后面可以匹配的可以使 a-z 和 A-Z 以及 %
当是连续的两个 %% 时就会被识别成转义成实际的 %
public static void main(String[] args) { |
换成这样就能正常输出了
]]>public static void start(String input) { |
就是带了个参数,这边是我把参数打了出来,如果没有打,我想通过agent来知道这个参数值是啥就可以用agent技术
获取代码中的变量名以及类型
MethodInfo methodInfo = declaredMethod.getMethodInfo(); |
这边就是个string类型,我们就能够获取到 input 这个变量名,然后我们就可以在这里插入一段代码来打印这个参数
declaredMethod.insertAfter("System.out.println( " + attribute.variableName(0)+ " );"); |
这样我们就能做到类似于java中切面的技术
]]>public Author { |
注解可以打在类上,那么我们建一个point类
|
name 是 nick,24年的,
然后我想通过javassist来获取这个类上的注解信息
我们先从对象池中获取这个类
CtClass cc = ClassPool.getDefault().get("org.example.Point"); |
然后获取类上的注解
Object[] all = cc.getAnnotations(); |
将第一个注解强转成Author,因为这里我们知道是只有这个注解,否则可以做的更通用一点
然后把这个主机上的值获取出来
String name = a.name(); |
可以获得结果,非常简单
name: nick, year: 2024 |
为什么讲这么个简单的例子呢,因为这个刚好可以作为一种实现aop的途径,我们可以获取类的信息,包括注解上的,这样我们就可以从源头去理解这些aop啥的可以通过什么方法来实现
]]>public class DemoService { |
就是一个方法,输入几个字符串,然后加到list里,那么比如我们想知道打印入参和返回结果
这里比较类似于我们在用aop的时候就是织入代码
正好javassist有这样的操作接口
就是我们可以找到方法,然后使用
javassist.CtBehavior#insertBefore(java.lang.String) |
和
javassist.CtBehavior#insertAfter(java.lang.String) |
就可以在我们找到类和方法以后
ClassPool pool = ClassPool.getDefault(); |
对方法的前后进行逻辑织入
method.insertBefore( |
这里我们使用了直接织入代码的形式,在javassist中可以用 $args 来获取参数,然后循环参数, 把每个参数拼接以后作为字符串输出
然后我们想要在函数返回前获取返回值,这个也是有个语法糖 $_
StringBuilder after = new StringBuilder(); |
这里刚好我是list返回的,就直接这么处理了, 我们通过一个简单的调用来验证下
public static void main(String[] args) throws Exception { |
这里其实核心很依赖两个语法糖,类似这样的还有一些
$0, $1, $2, ... this and actual parameters |
可以结合文档仔细学习下
]]>public static void createEntity() throws Exception { |
这个代码可以给我们创建一个Entity类, 带有一个无参的构造函数,默认在项目根目录下会生成Entity类的class文件
但是其实这个也是不必要的,默认会给生成一个无参的构造函数
然后我们可以给这个类加个字段, 加在 writeFile 方法调用前
CtField param = new CtField(pool.get("java.lang.String"), "name", cl); |

我们就生成了这样一个类
javassist也已经提供好了
cl.addMethod(CtNewMethod.setter("setName", param)); |
我们生成的类就变成这样了
接下去我们可以再加一个默认赋值的无参构造函数
CtConstructor con = new CtConstructor(new CtClass[]{}, cl); |

然后我们就有了这样的类,带有一个默认赋值的构造函数,接下去可以来个带参数的构造函数
con = new CtConstructor(new CtClass[]{pool.get("java.lang.String")}, cl); |

最后我们可以再加个打印该字段的方法
CtMethod ctMethod = new CtMethod(CtClass.voidType, "printName", new CtClass[]{}, cl); |
这样我们就获得了这样一个类
这只是javassist的简单使用,它还有很多强大的功能可以在官方文档和网上的资料进行学习
spctl 好像是需要进恢复模式的sudo spctl --master-disable |
关闭后重新打开系统设置
就能看到任意来源了
捎带解释下这个 spctl 的意思是 System Policy Control
用于管理系统策略控制。 禁用Gatekeeper的主开关,允许运行任何来源的应用。
此命令会降低Mac的安全性,因为它允许运行未经验证的应用。 启用后,需小心下载和运行应用。
所以还是需要小心关闭,一般在确认来源可靠才能关闭
Given an array of n positive integers and a positive integer s, find the minimal length of a subarray of which the sum ≥ s. If there isn’t one, return 0 instead.
For example, given the array [2,3,1,2,4,3] and s = 7,
the subarray [4,3] has the minimal length under the problem constraint.
参考,滑动窗口,跟之前Data Structure课上的online算法有点像,链接
class Solution { |
在C++中,应该是从C语言就开始了,除了void型指针之外都是需要有分配对应的内存才可以使用,同时malloc与free成对使用,new与delete成对使用,否则造成内存泄漏。
]]><!ELEMENT foreach (#PCDATA | include | trim | where | set | foreach | choose | if | bind)*> |
collection 表示需要使用 foreach 的集合,item 表示进行迭代的变量名,index 就是索引值,而 open 跟 close
代表拼接的起始和结束符号,一般就是左右括号,separator 则是每个 item 直接的分隔符
例如写了一个简单的 sql 查询
<select id="search" parameterType="list" resultMap="StudentMap"> |
这里就发现了一个问题,collection 对应的这个值,如果传入的参数是个 HashMap,collection 的这个值就是以此作为
key 从这个 HashMap 获取对应的集合,但是这里有几个特殊的小技巧,
在上面的这个方法对应的接口方法定义中
public List<Student> search(List<Long> userIds); |
我是这么定义的,而 collection 的值是list,这里就有一点不能理解了,但其实是 mybatis 考虑到使用的方便性,
帮我们做了一点点小转换,我们翻一下 mybatis 的DefaultSqlSession 中的代码可以看到
|
select * from t1 where id = #{id}这样的 sql,在初始化扫描 mapper 的xml文件的时候会根据是否是 dynamic 来判断生成 DynamicSqlSource 还是 RawSqlSource,这里它是一条 RawSqlSource,#{}替换成了?// org.apache.ibatis.scripting.xmltags.XMLScriptBuilder#parseScriptNode |
可以看到其中一个条件就是是否有${}这种占位符,假如说上面的 sql 换成 ${},那么可以看到它会在这里创建一个 dynamicSqlSource,
// org.apache.ibatis.scripting.xmltags.DynamicSqlSource |
这里眼尖的同学可能就可以看出来了,RawSqlSource 在初始化的时候已经经过了 parse,把#{}替换成了?占位符,但是 DynamicSqlSource 并没有
再看这个图,我们发现在这的时候还没有进行替换
然后往里跟
好像是这里了
这里 rootSqlNode.apply 其实是一个对原来 sql 的解析结果的一个循环调用,不同类型的标签会构成不同的 node,像这里就是一个 textSqlNode
可以发现到这我们的 sql 已经被替换了,而且是直接作为 string 类型替换的,所以可以明白了这个问题所在,就是注入,不过细心的同学发现其实这里是有个
理论上还是可以做过滤的,不过好像现在没用起来。
我们前面可以发现对于#{}是在启动扫描 mapper的 xml 文件就替换成了 ?,然后是在什么时候变成实际的值的呢
发现到这的时候还是没有替换,其实说白了也就是 prepareStatement 那一套,
在这里进行替换,会拿到 org.apache.ibatis.mapping.ParameterMapping,然后进行替换,因为会带着类型信息,所以不用担心注入咯
闲扯这么多来说说 mybatis 的缓存,mybatis 一般作为一个轻量级的 orm 使用,相对应的就是比较重量级的 hibernate,不过不在这次讨论范围,上一次是主要讲了 mybatis 在解析 sql 过程中,对于两种占位符的不同替换实现策略,这次主要聊下 mybatis 的缓存,前面其实得了解下前置的东西,比如 sqlsession,先当做我们知道 sqlsession 是个什么玩意,可能或多或少的知道 mybatis 是有两级缓存,
第一级的缓存是在 BaseExecutor 中的 PerpetualCache,它是个最基本的缓存实现类,使用了 HashMap 实现缓存功能,代码其实没几十行
public class PerpetualCache implements Cache { |
可以看一下BaseExecutor 的构造函数
protected BaseExecutor(Configuration configuration, Transaction transaction) { |
就是把 PerpetualCache 作为 localCache,然后怎么使用我看简单看一下,BaseExecutor 的查询首先是调用这个函数
|
可以看到首先是调用了 createCacheKey 方法,这个方法呢,先不看怎么写的,如果我们自己要实现这么个缓存,首先这个缓存 key 的设计也是个问题,如果是以表名加主键作为 key,那么分页查询,或者没有主键的时候就不行,来看看 mybatis 是怎么设计的
|
首先需要 id,这个 id 是 mapper 里方法的 id, 然后是偏移量跟返回行数,再就是 sql,然后是参数,基本上是会有影响的都加进去了,在这个 update 里面
public void update(Object object) { |
其实是一个 hash 转换,具体不纠结,就是提高特异性,然后回来就是继续调用 query
|
可以看到是先从 localCache 里取,取不到再 queryFromDatabase,其实比较简单,这是一级缓存,考虑到 sqlsession 跟 BaseExecutor 的关系,其实是随着 sqlsession 来保证这个缓存不会出现脏数据幻读的情况,当然事务相关的后面可能再单独聊。
其实这个一级二级顺序有点反过来,其实查询的是先走的二级缓存,当然二级的需要配置开启,默认不开,
需要通过
<setting name="cacheEnabled" value="true"/> |
来开启,然后我们的查询就会走到
public class CachingExecutor implements Executor { |
这个 Executor 中,这里我放了类里面的元素,发现没有一个 Cache 类,这就是一个特点了,往下看查询过程
|
看到没,其实缓存是从 tcm 这个成员变量里取,而这个是什么呢,事务性缓存(直译下),因为这个其实是用 MappedStatement 里的 Cache 作为key 从 tcm 的 map 取出来的
public class TransactionalCacheManager { |
MappedStatement是被全局使用的,所以其实二级缓存是跟着 mapper 的 namespace 走的,可以被多个 CachingExecutor 获取到,就会出现线程安全问题,线程安全问题可以用SynchronizedCache来解决,就是加锁,但是对于事务中的脏读,使用了TransactionalCache来解决这个问题,
public class TransactionalCache implements Cache { |
在事务还没提交的时候,会把中间状态的数据放在 entriesToAddOnCommit 中,只有在提交后会放进共享缓存中,
public void commit() { |
selectOne跟语句id就能执行sql了,那么第一个问题,就是mapper是怎么被解析的,存在哪里,怎么被拿出来的
org.apache.ibatis.session.SqlSessionFactoryBuilder#build(java.io.InputStream) |
通过读取mybatis-config.xml来构建SqlSessionFactory,
public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) { |
创建XMLConfigBuilder
public XMLConfigBuilder(InputStream inputStream, String environment, Properties props) { |
这里主要是创建了Builder包含了Parser
然后调用parse方法
public Configuration parse() { |
实际的解析区分了各类标签
private void parseConfiguration(XNode root) { |
然后就是调用到mapperElement方法了
private void mapperElement(XNode parent) throws Exception { |
核心就在这个parse()方法
public void parse() { |
具体的处理逻辑
private void configurationElement(XNode context) { |
具体代码在这,从上下文构建statement,只不过区分了下databaseId
private void buildStatementFromContext(List<XNode> list) { |
判断下databaseId
private void buildStatementFromContext(List<XNode> list, String requiredDatabaseId) { |
接下来就是真正处理的xml语句内容的,各个节点的信息内容
public void parseStatementNode() { |
添加的逻辑具体可以看下
public MappedStatement addMappedStatement( |
而里面就是往map里添加
public void addMappedStatement(MappedStatement ms) { |
StudentDO studentDO = session.selectOne("com.nicksxs.mybatisdemo.StudentMapper.selectStudent", 1); |
就是调用了 org.apache.ibatis.session.defaults.DefaultSqlSession#selectOne(java.lang.String, java.lang.Object)
public <T> T selectOne(String statement, Object parameter) { |
调用实际的实现方法
public <E> List<E> selectList(String statement, Object parameter) { |
这里还有一层
public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) { |
根本的就是从configuration里获取了mappedStatement
private <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler) { |
private PooledConnection popConnection(String username, String password) throws SQLException { |
然后是还回连接
protected void pushConnection(PooledConnection conn) throws SQLException { |
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); |
在构建 SqlSessionFactory 也就是 DefaultSqlSessionFactory 的时候,
public SqlSessionFactory build(InputStream inputStream) { |
前面也说过,就是解析 mybatis-config.xml 成 Configuration
public Configuration parse() { |
环境解析了这一块的内容
<environments default="development"> |
解析也是自上而下的,
private void environmentsElement(XNode context) throws Exception { |
前面第一步是解析事务管理器元素
private TransactionFactory transactionManagerElement(XNode context) throws Exception { |
而这里的 resolveClass 其实就使用了上一篇的 typeAliases 系统,这里是使用了 JdbcTransactionFactory 作为事务管理器,
后面的就是 DataSourceFactory 的创建也是 DataSource 的创建
private DataSourceFactory dataSourceElement(XNode context) throws Exception { |
因为在config文件中设置了Pooled,所以对应创建的就是 PooledDataSourceFactory
但是这里其实有个比较需要注意的,mybatis 这里的其实是继承了 UnpooledDataSourceFactory
将基础方法都放在了 UnpooledDataSourceFactory 中
public class PooledDataSourceFactory extends UnpooledDataSourceFactory { |
这里只保留了在构造方法里创建 DataSource
而这个 PooledDataSource 虽然没有直接继承 UnpooledDataSource,但其实
在构造方法里也是
public PooledDataSource() { |
至于为什么这么做呢应该也是考虑到能比较多的复用代码,因为 Pooled 其实跟 Unpooled 最重要的差别就在于是不是每次都重开连接
使用连接池能够让应用在有大量查询的时候不用反复创建连接,省去了建联的网络等开销,Unpooled就是完成与数据库的连接,并可以获取该连接
主要的代码
|
而对于Pooled就会处理池化的逻辑
private PooledConnection popConnection(String username, String password) throws SQLException { |
它的入口不是个get方法,而是pop,从含义来来讲就不一样org.apache.ibatis.datasource.pooled.PooledDataSource#getConnection()
|
对于具体怎么获取连接我们可以下一篇具体讲下
]]>mapperElement(root.evalNode("mappers")); |
具体的代码会执行到这
private void mapperElement(XNode parent) throws Exception { |
然后再是 parse 过程
public void parse() { |

继续往下走
private void configurationElement(XNode context) { |
然后是
private void buildStatementFromContext(List<XNode> list) { |
继续
private void buildStatementFromContext(List<XNode> list, String requiredDatabaseId) { |
这个代码比较长,做下简略,只保留相关代码
public void parseStatementNode() { |
然后根据 LanguageDriver,我们这用的 XMLLanguageDriver,先是初始化
|
初始化解析器以后就开始解析了
public SqlSource parseScriptNode() { |
但是这里可能做的事情比较多
protected MixedSqlNode parseDynamicTags(XNode node) { |
再看下 handleNode 的逻辑
|
再回过来
public SqlSource parseScriptNode() { |
这里就做完了预处理工作,真正在执行的执行的时候还需要进一步解析
因为前面讲过很多了,所以直接跳到这里
|

我们重点看 foreach 的逻辑
|

可以看到这里,然后再进行替换

真实的从 ? 替换成具体的变量值,是在这里org.apache.ibatis.executor.SimpleExecutor#doQuery
调用了
private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException { |
比如这样
public static void main(String[] args) { |
打印出来就是
SELECT id, name |
应付简单的 sql 查询基本都可以这么解决,如果习惯这种模式,还是不错的,
其实以面向对象的编程模式来说,这样是比较符合面向对象的,先不深入的解析这块的源码,先从使用角度讲一下
String updateSql = new SQL() {{ |
打印输出就是
UPDATE student |
String insertSql = new SQL() {{ |
打印输出
INSERT INTO student |
String deleteSql = new SQL() {{ |
打印输出
DELETE FROM student |
String selectSql = new SQL() {{ |
SELECT 方法的实现,
public T SELECT(String... columns) { |
statementType是个枚举
public enum StatementType { |
那这个就是个 select 语句,然后会把参数转成 list 添加到 select 变量里,
然后是 from 语句,这个大概也能猜到就是设置下表名,
public T FROM(String table) { |
往 tables 里添加了 table,这个 tables 是什么呢
这里也可以看下所有的变量,
StatementType statementType; |
可以看到是一堆 List 先暂存这些sql 片段,然后再拼装成 sql 语句,
因为它重写了 toString 方法
|
调用的 sql 方法是
public String sql(Appendable a) { |
根据上面的 statementType判断是个什么 sql,我们这个是 selectSQL 就走的 SELECT 这个分支
private String selectSQL(SafeAppendable builder) { |
上面的可以看出来就是按我们常规的 sql 理解顺序来处理
就是select ... from ... where ... 这样子
再看下 sqlClause 的代码
private void sqlClause(SafeAppendable builder, String keyword, List<String> parts, String open, String close, |
这里的拼接方式还需要判断 AND 和 OR 的判断逻辑,其他就没什么特别的了,只是where 语句中的 lastList 不知道是干嘛的,好像只有添加跟赋值的操作,有知道的大神也可以评论指导下
]]><typeAliases> |
可以在这里注册类型别名,然后在mybatis中配置使用时,可以简化这些类型的使用,其底层逻辑主要是一个map,
public class TypeAliasRegistry { |
以string作为key,class对象作为value,比如我们在一开始使用的配置文件
<dataSource type="POOLED"> |
这里使用的dataSource是POOLED,那它肯定是个别名或者需要对应处理
而这个别名就是在Configuration的构造方法里初始化
public Configuration() { |
正是通过typeAliasRegistry.registerAlias("POOLED", PooledDataSourceFactory.class);这一行,注册了POOLED对应的别名类型是PooledDataSourceFactory.class
具体的注册方法是在
public void registerAlias(String alias, Class<?> value) { |
而获取的逻辑在这
public <T> Class<T> resolveAlias(String string) { |
逻辑比较简单,但是在mybatis中也是不可或缺的一块概念
]]>MyBatis 是一款优秀的持久层框架,它支持自定义 SQL、存储过程以及高级映射。MyBatis 免除了几乎所有的 JDBC 代码以及设置参数和获取结果集的工作。MyBatis 可以通过简单的 XML 或注解来配置和映射原始类型、接口和 Java POJO(Plain Old Java Objects,普通老式 Java 对象)为数据库中的记录。
mybatis一大特点,或者说比较为人熟知的应该就是比 hibernate 是更轻量化,为国人所爱好的orm框架,对于hibernate目前还没有深入的拆解过,后续可以也写一下,在使用体验上觉得是个比较精巧的框架,看代码也比较容易,所以就想写个系列,第一篇先是介绍下使用
根据官网的文档上我们先来尝试一下简单使用
首先我们有个简单的配置,这个文件是mybatis-config.xml
|
在代码里创建mybatis里重要入口
String resource = "mybatis-config.xml"; |
然后我们上面的StudentMapper.xml
|
那么我们就要使用这个mapper,
String resource = "mybatis-config.xml"; |
sqlSessionFactory是sqlSession的工厂,我们可以通过sqlSessionFactory来创建sqlSession,而SqlSession 提供了在数据库执行 SQL 命令所需的所有方法。你可以通过 SqlSession 实例来直接执行已映射的 SQL 语句。可以看到mapper.xml中有定义mapper的namespace,就可以通过session.selectOne()传入namespace+id来调用这个方法
但是这样调用比较不合理的点,或者说按后面mybatis优化之后我们可以指定mapper接口
public interface StudentMapper { |
就可以可以通过mapper接口获取方法,这样就不用涉及到未知的变量转换等异常
try (SqlSession session = sqlSessionFactory.openSession()) { |
这一篇咱们先介绍下简单的使用,后面可以先介绍下这些的原理。
]]>languageDriverorg/mybatis/mybatis/3.5.11/mybatis-3.5.11-sources.jar!/org/apache/ibatis/session/Configuration.java:215configuration的构造方法里
languageRegistry.setDefaultDriverClass(XMLLanguageDriver.class); |
而在org.apache.ibatis.builder.xml.XMLStatementBuilder#parseStatementNode
中,创建了sqlSource,这里就会根据前面的 LanguageDriver 的实现选择对应的 sqlSource ,
SqlSource sqlSource = langDriver.createSqlSource(configuration, context, parameterTypeClass); |
createSqlSource 就会调用
|
再往下的逻辑在 parseScriptNode 中,org.apache.ibatis.scripting.xmltags.XMLScriptBuilder#parseScriptNode
public SqlSource parseScriptNode() { |
首先要解析dynamicTag,调用了org.apache.ibatis.scripting.xmltags.XMLScriptBuilder#parseDynamicTags
protected MixedSqlNode parseDynamicTags(XNode node) { |
判断是否是动态sql,调用了org.apache.ibatis.scripting.xmltags.TextSqlNode#isDynamic
public boolean isDynamic() { |
创建parser的时候可以看到这个parser是干了啥,其实就是找有没有${ , }
private GenericTokenParser createParser(TokenHandler handler) { |
如果是的话,就在上面把 isDynamic 设置为true 如果是true 的话就创建 DynamicSqlSource
sqlSource = new DynamicSqlSource(configuration, rootSqlNode); |
如果不是的话就创建RawSqlSource
sqlSource = new RawSqlSource(configuration, rootSqlNode, parameterType); |
具体的sqlSource是通过org.apache.ibatis.builder.SqlSourceBuilder#parse 创建的
具体的代码逻辑是
public SqlSource parse(String originalSql, Class<?> parameterType, Map<String, Object> additionalParameters) { |
这里创建的其实是StaticSqlSource ,多带一句前面的parser是将原来这样select * from student where id = #{id} 的 sql 解析成了select * from student where id = ? 然后创建了StaticSqlSource
public StaticSqlSource(Configuration configuration, String sql, List<ParameterMapping> parameterMappings) { |
为什么前面要讲这么多好像没什么关系的代码呢,其实在最开始我们执行sql的代码中
|
这里获取了BoundSql,而BoundSql是怎么来的呢,首先调用了org.apache.ibatis.mapping.MappedStatement#getBoundSql
public BoundSql getBoundSql(Object parameterObject) { |
而我们从上面的解析中可以看到这里的sqlSource是一层RawSqlSource , 它的getBoundSql又是调用内部的sqlSource的方法
|
内部的sqlSource 就是StaticSqlSource ,
|
这个BoundSql的内容也比较简单
public BoundSql(Configuration configuration, String sql, List<ParameterMapping> parameterMappings, Object parameterObject) { |
而上次在这边org.apache.ibatis.executor.SimpleExecutor#doQuery 的时候落了个东西,就是StatementHandler的逻辑
|
它是通过statementType来区分应该使用哪个statementHandler,我们这使用的就是PreparedStatementHandler
public RoutingStatementHandler(Executor executor, MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) { |
所以上次有个细节可以补充,这边的doQuery里面的handler.query 应该是调用了PreparedStatementHandler 的query方法
|
因为上面prepareStatement中getConnection拿到connection是com.mysql.cj.jdbc.ConnectionImpl#ConnectionImpl(com.mysql.cj.conf.HostInfo)
|
那又为什么是这个呢,可以在网上找,我们在mybatis-config.xml里配置的
<transactionManager type="JDBC"/> |
因此在parseConfiguration中配置environment时
private void parseConfiguration(XNode root) { |
调用的这个方法通过获取xml中的transactionManager 配置的类型,也就是JDBC
private void environmentsElement(XNode context) throws Exception { |
是通过以下方法获取的,
// 方法全限定名 org.apache.ibatis.builder.xml.XMLConfigBuilder#transactionManagerElement |
而通过JDBC获取得是啥的,就是在Configuration的构造方法里写了的JdbcTransactionFactory
public Configuration() { |
所以我们在这
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) { |
获得到的TransactionFactory 就是 JdbcTransactionFactory ,而后
tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit); |
然后我们再会上去看代码getConnection ,
protected Connection getConnection(Log statementLog) throws SQLException { |
即调用了
|
其实就是调用的
// org.apache.ibatis.datasource.unpooled.UnpooledDataSource#getConnection() |
继续这个逻辑
private Connection doGetConnection(Properties properties) throws SQLException { |
上面的driver就是driver[className=com.mysql.cj.jdbc.Driver@64030b91]
// com.mysql.cj.jdbc.NonRegisteringDriver#connect |
这是个 SINGLE_CONNECTION ,所以调用的就是 return ConnectionImpl.getInstance(conStr.getMainHost());
然后在这里设置了代理类
public PooledConnection(Connection connection, PooledDataSource dataSource) { |
结合这个
|
所以最终的connection就是com.mysql.cj.jdbc.ConnectionImpl@358ab600
]]>org.apache.ibatis.builder.xml.XMLConfigBuilder 创建了parser解析器,那么解析的结果是什么public Configuration parse() { |
返回的是 org.apache.ibatis.session.Configuration , 而这个 Configuration 也是 mybatis 中特别重要的配置核心类,贴一下里面的成员变量,
public class Configuration { |
这么多成员变量,先不一一解释作用,但是其中的几个参数我们应该是已经知道了的,第一个就是 mappedStatements ,上一篇我们知道被解析的mapper就是放在这里,后面的 resultMaps ,parameterMaps 也比较常用的就是我们参数和结果的映射map,这里跟我之前有一篇解释为啥我们一些变量的使用会比较特殊,比如list,可以参考这篇,keyGenerators是在我们需要定义主键生成器的时候使用。
然后第二点是我们创建的 org.apache.ibatis.session.SqlSessionFactory 是哪个,
public SqlSessionFactory build(Configuration config) { |
是这个 DefaultSqlSessionFactory ,这是其中一个 SqlSessionFactory 的实现
接下来我们看看 openSession 里干了啥
public SqlSession openSession() { |
这边有几个参数,第一个是默认的执行器类型,往上找找上面贴着的 Configuration 的成员变量里可以看到默认是protected ExecutorType defaultExecutorType = ExecutorType.SIMPLE;
因为没有指明特殊的执行逻辑,所以默认我们也就用简单类型的,第二个参数是是事务级别,第三个是是否自动提交
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) { |
具体是调用了 Configuration 的这个方法
public Executor newExecutor(Transaction transaction, ExecutorType executorType) { |
上面传入的 executorType 是 Configuration 的默认类型,也就是 simple 类型,并且 cacheEnabled 在 Configuration 默认为 true,所以会包装成CachingExecutor ,然后后面就是插件了,这块我们先不展开
然后我们的openSession返回的就是创建了DefaultSqlSession
public DefaultSqlSession(Configuration configuration, Executor executor, boolean autoCommit) { |
然后就是调用 selectOne, 因为前面已经把这部分代码说过了,就直接跳转过来org.apache.ibatis.session.defaults.DefaultSqlSession#selectList(java.lang.String, java.lang.Object, org.apache.ibatis.session.RowBounds, org.apache.ibatis.session.ResultHandler)
private <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler) { |
因为前面说了 executor 包装了 CachingExecutor ,所以会先调用
|
然后是调用的真实的query方法
|
这里是第一次查询,没有缓存就先到最后一行,继续是调用到 org.apache.ibatis.executor.BaseExecutor#queryFromDatabase
|
然后是
private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { |
然后就是 simpleExecutor 的执行过程
|
接下去其实就是跟jdbc交互了
|
com.mysql.cj.jdbc.ClientPreparedStatement#execute
public boolean execute() throws SQLException { |
默认的格式是预定义的 combined
log_format combined '$remote_addr - $remote_user [$time_local] ' |
配置的日志可以使用这个默认的,如果满足需求的话
Syntax: access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]]; |
而如果需要额外的一些配置的话可以自己定义 log_format ,比如我想要给日志里加上请求时间,那就可以自己定义一个 log_format 比如添加下
$request_time |
log_format combined_extend '$remote_addr - $remote_user [$time_local] ' |
然后其他的比如还有 gzip 压缩,可以设置压缩级别,flush 刷盘时间还有根据条件控制
这里的条件控制简单看了下还比较厉害
比如我想对2xx 跟 3xx 的访问不记录日志
map $status $loggable { |
当 $loggable 是 0 或者空时表示 if 条件为否,上面的默认就是 1,只有当请求状态 status 是 2xx 或 3xx 时才是 0,代表不用记录,有了这个特性就可以更灵活地配置日志
文章主要参考了 nginx 的 log 模块的文档
]]>首先是日志error_log logs/error.log debug;
需要nginx开启日志的debug才能看到日志
使用 lua_code_cache off即可, 另外注意只有使用 content_by_lua_file 才会生效
http { |
使用lua给nginx请求response头添加内容可以用这个
ngx.header['response'] = 'header' |
后续:
一开始在本地环境的时候使用content_by_lua_file只关注了头,后来发到测试环境发现请求内容都没代理转发到后端服务上
网上查了下发现content_by_lua_file是将请求的所有内容包括response都用这里面的lua脚本生成了,content这个词就表示是请求内容
后来改成了access_by_lua_file就正常了,只是要去获取请求内容和修改响应头,并不是要完整的接管请求
后来又碰到了一个坑是nginx有个client_body_buffer_size的配置参数,nginx在32位和64位系统里有8K和16K两个默认值,当请求内容大于这两个值的时候,会把请求内容放到临时文件里,这个时候openresty里的ngx.req.get_post_args()就会报“failed to get post args: requesty body in temp file not supported”这个错误,将client_body_buffer_size这个参数配置调大一点就好了
还有就是lua的异常捕获,网上看一般是用pcall和xpcall来进行保护调用,因为问题主要出在cjson的decode,这里有两个解决方案,一个就是将cjson.decode使用pcall封装,
local decode = require("cjson").decode |
这个是使用了pcall,称为保护调用,会在内部错误后返回两个参数,第一个是false,第二个是错误信息
还有一种是使用cjson.safe包
local json = require("cjson.safe") |
cjson.safe包会在解析失败的时候返回nil
还有一个是redis链接时如果host使用的是域名的话会提示“failed to connect: no resolver defined to resolve “redis.xxxxxx.com””,这里需要使用nginx的resolver指令,
resolver 8.8.8.8 valid=3600s;
还有一点补充下
就是业务在使用redis的时候使用了db的特性,所以在lua访问redis的时候也需要执行db,这里lua的redis库也支持了这个特性,可以使用instance:select(config:get(‘db’))来切换db
发现一个不错的openresty站点
地址
Perl Compatible Regular Expressions (PCRE) is a regular
expression C library inspired by the regular expression
capabilities in the Perl programming language, written
by Philip Hazel, starting in summer 1997.
因为最近工作内容的一部分需要做字符串的识别处理,所以就顺便用上了之前在PHP中用过的正则,在C/C++中本身不包含正则库,这里使用的pcre,对MFC开发,在这里提供了静态链接库,在引入lib跟.h文件后即可使用。
然后是一些正则语法,官方的语法文档比较科学严谨,特别是对类似于贪婪匹配等细节的说明,当然一般的使用可以在网上找到很多匹配语法,例如这个。
pcre_compile
原型:
|
功能:将一个正则表达式编译成一个内部表示,在匹配多个字符串时,可以加速匹配。其同pcre_compile2功能一样只是缺少一个参数errorcodeptr。
参数:pattern 正则表达式options 为0,或者其他参数选项errptr 出错消息erroffset 出错位置tableptr 指向一个字符数组的指针,可以设置为空NULL
pcre_exec
原型:
|
功能:使用编译好的模式进行匹配,采用与Perl相似的算法,返回匹配串的偏移位置。
参数:code 编译好的模式extra 指向一个pcre_extra结构体,可以为NULLsubject 需要匹配的字符串length 匹配的字符串长度(Byte)startoffset 匹配的开始位置options 选项位ovector 指向一个结果的整型数组ovecsize 数组大小。
这里是两个最常用的函数的简单说明,pcre的静态库提供了一系列的函数以供使用,可以参考这个博客说明,另外对于以上函数的具体参数详细说明可以参考官网此处
void COcxDemoDlg::pcre_exec_all(const pcre * re, PCRE_SPTR src, vector<pair<int, int>> &vc) |
vector中是全文匹配后的索引对,只是简单地用下。
]]><?php |
PHP Fatal error: Abstract function abst1::abstra1() cannot contain body in new.php on line 17 |
echo 111;exit; 但是对于使用了接口和继承比较多的话,有时候比较难找,可能定位到了一段代码但是不知道怎么调用过来的,这时候就可以用这个方法
总结下来有三种,
function a() { |
比如本来是上面这样子,那么其实我们可以主动new 个异常
function a() { |
这样我的 trace 调用链路就出来了
这个就是比较简单的,调用 php 自身提供的方法
debug_backtrace(int $options = DEBUG_BACKTRACE_PROVIDE_OBJECT, int $limit = 0): array |
第一个参数是个掩码
| debug_backtrace() | Populates both indexes |
|---|---|
| debug_backtrace(DEBUG_BACKTRACE_PROVIDE_OBJECT) | |
| debug_backtrace(1) | |
| debug_backtrace(0) | Omits index "object" and populates index "args". |
| debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS) | Omits index "object" and index "args". |
| debug_backtrace(2) | |
| debug_backtrace(DEBUG_BACKTRACE_PROVIDE_OBJECT | DEBUG_BACKTRACE_IGNORE_ARGS) |
| debug_backtrace(3) |
第二个参数是限制栈深度
这个也是用自身的方法
debug_print_backtrace(int $options = 0, int $limit = 0): void |
这里的第一个参数只有一个可以传的
| DEBUG_BACKTRACE_IGNORE_ARGS | Whether or not to omit the “args” index, and thus all the function/method arguments, to save memory. |
|---|
就是隐藏参数,不然如果对于一些框架代码,这个打印会非常大,需要注意下
]]>变量命名类似于php
PS C:\Users\Nicks> $a=1 |
有一个比较好用的是变量交换
一般的语言做两个变量交换一般需要一个临时变量
tmp=$a |
而在powershell中可以这样
$a,$b=$b,$a |
还可以通过这个
PS C:\Users\Nicks> ls variable: |
查看现存的变量
当然一般脚本都是动态类型的,
可以通过
gettype方法
$nums=2,0,1,2 |
顺便可以用下我们上次学到的gettype()
如果是想创建连续数字的数组还可以用这个方便的方法
$nums=1..5 |

而且数组还可以存放各种类型的数据
$array=1,"哈哈",([System.Guid]::NewGuid()),(get-date) |

还有判断类型可以用-is
创建一个空数组
$array=@() |

数组添加元素
$array+="a" |

数组删除元素
$a=1..4 |

接触了一下rabbitmq,原来在选型的时候是在rabbitmq跟kafka之间做选择,网上搜了一下之后发现kafka的优势在于吞吐量,而rabbitmq相对注重可靠性,因为应用在im上,需要保证消息不能丢失所以就暂时选定rabbitmq,
Message Queue的需求由来已久,80年代最早在金融交易中,高盛等公司采用Teknekron公司的产品,当时的Message queuing软件叫做:the information bus(TIB)。 TIB被电信和通讯公司采用,路透社收购了Teknekron公司。之后,IBM开发了MQSeries,微软开发了Microsoft Message Queue(MSMQ)。这些商业MQ供应商的问题是厂商锁定,价格高昂。2001年,Java Message queuing试图解决锁定和交互性的问题,但对应用来说反而更加麻烦了。
RabbitMQ采用Erlang语言开发。Erlang语言由Ericson设计,专门为开发concurrent和distribution系统的一种语言,在电信领域使用广泛。OTP(Open Telecom Platform)作为Erlang语言的一部分,包含了很多基于Erlang开发的中间件/库/工具,如mnesia/SASL,极大方便了Erlang应用的开发。OTP就类似于Python语言中众多的module,用户借助这些module可以很方便的开发应用。
于是2004年,摩根大通和iMatrix开始着手Advanced Message Queuing Protocol (AMQP)开放标准的开发。2006年,AMQP规范发布。2007年,Rabbit技术公司基于AMQP标准开发的RabbitMQ 1.0 发布。所有主要的编程语言均有与代理接口通讯的客户端库。
这里介绍下其中的一些概念,connection表示和队列服务器的连接,一般情况下是tcp连接, channel表示通道,可以在一个连接上建立多个通道,这里主要是节省了tcp连接握手的成本,exchange可以理解成一个路由器,将消息推送给对应的队列queue,其实是像一个订阅的模式。
rabbitmqctl stop这个是关闭rabbitmq,在搭建集群时候先关闭服务,然后使用rabbitmq-server -detached静默启动,这时候使用rabbitmqctl cluster_status查看集群状态,因为还没将节点加入集群,所以只能看到类似
Cluster status of node rabbit@rabbit1 ... |
然后就可以把当前节点加入集群,
rabbitmqctl stop_app #这个stop_app与stop的区别是前者停的是rabbitmq应用,保留erlang节点, |
其他可以参考官方文档
这里碰到过一个坑,对于使用exchange来做消息路由的,会有一个情况,就是在routing_key没被订阅的时候,会将该条找不到路由对应的queue的消息丢掉What happens if we break our contract and send a message with one or four words, like "orange" or "quick.orange.male.rabbit"? Well, these messages won't match any bindings and will be lost.对应链接,而当使用空的exchange时,会保留消息,当出现消费者的时候就可以将收到之前生产者所推送的消息对应链接,这里就是用了空的exchange。
集群搭建的时候有个erlang vm生成的random cookie,这个是用来做集群之间认证的,相同的cookie才能连接,但是如果通过vim打开复制后在其他几点新建文件写入会多一个换行,导致集群建立是报错,所以这里最好使用scp等传输命令直接传输cookie文件,同时要注意下cookie的文件权限。
另外在集群搭建的时候如果更改过hostname,那么要把rabbitmq的数据库删除,否则启动后会马上挂掉
fork()之后,kernel把父进程中所有的内存页的权限都设为read-only,然后子进程的地址空间指向父进程。当父子进程都只读内存时,相安无事。当其中某个进程写内存时,CPU硬件检测到内存页是read-only的,于是触发页异常中断(page-fault),陷入kernel的一个中断例程。中断例程中,kernel就会把触发的异常的页复制一份,于是父子进程各自持有独立的一份。这个操作其实可以类比为写屏障,正常的读取是没问题的,当有写入时就会分裂。
1、减少分配和复制资源时带来的瞬时延迟;
2、减少不必要的资源分配;
CopyOnWrite的缺点:
1、如果父子进程都需要进行大量的写操作,会产生大量的分页错误(页异常中断page-fault);
Redis在持久化时,如果是采用BGSAVE命令或者BGREWRITEAOF的方式,那Redis会fork出一个子进程来读取数据,从而写到磁盘中。
总体来看,Redis还是读操作比较多。如果子进程存在期间,发生了大量的写操作,那可能就会出现很多的分页错误(页异常中断page-fault),这样就得耗费不少性能在复制上。
而在rehash阶段上,写操作是无法避免的。所以Redis在fork出子进程之后,将负载因子阈值提高,尽量减少写操作,避免不必要的内存写入操作,最大限度地节约内存。这里其实更巧妙了,在细节上去优化会产生大量页异常中断的情况。
memcache之类的竞品,但是现在貌似 redis 快一统江湖,这里当然不是在吹,只是个人角度的一个感觉,不权威只是主观感觉。Strings,Lists,Sets,Hashes,Sorted Sets,这五种数据结构先简单介绍下,Strings类型的其实就是我们最常用的 key-value,实际开发中也会用的最多;Lists是列表,这个有些会用来做队列,因为 redis 目前常用的版本支持丰富的列表操作;还有是Sets集合,这个主要的特点就是集合中元素不重复,可以用在有这类需求的场景里;Hashes是叫散列,类似于 Python 中的字典结构;还有就是Sorted Sets这个是个有序集合;一眼看这些其实没啥特别的,除了最后这个有序集合,不过去了解背后的实现方式还是比较有意思的。
先从Strings开始说,了解过 C 语言的应该知道,C 语言中的字符串其实是个 char[] 字符数组,redis 也不例外,只是最开始的版本就对这个做了一丢丢的优化,而正是这一丢丢的优化,让这个 redis 的使用效率提升了数倍
struct sdshdr { |
这里引用了 redis 在 github 上最早的 2.2 版本的代码,代码路径是https://github.com/antirez/redis/blob/2.2/src/sds.h,可以看到这个结构体里只有仨元素,两个 int 型和一个 char 型数组,两个 int 型其实就是我说的优化,因为 C 语言本身的字符串数组,有两个问题,一个是要知道它实际已被占用的长度,需要去遍历这个数组,第二个就是比较容易踩坑的是遍历的时候要注意它有个以\0作为结尾的特点;通过上面的两个 int 型参数,一个是知道字符串目前的长度,一个是知道字符串还剩余多少位空间,这样子坐着两个操作从 O(N)简化到了O(1)了,还有第二个 free 还有个比较重要的作用就是能防止 C 字符串的溢出问题,在存储之前可以先判断 free 长度,如果长度不够就先扩容了,先介绍到这,这个系列可以写蛮多的,慢慢介绍吧
链表是比较常见的数据结构了,但是因为 redis 是用 C 写的,所以在不依赖第三方库的情况下只能自己写一个了,redis 的链表是个有头的链表,而且是无环的,具体的结构我也找了 github 上最早版本的代码
typedef struct listNode { |
代码地址是这个https://github.com/antirez/redis/blob/2.2/src/adlist.h
可以看下节点是由listNode承载的,包括值和一个指向前节点跟一个指向后一节点的两个指针,然后值是 void 指针类型,所以可以承载不同类型的值
然后是 list结构用来承载一个链表,包含了表头,和表尾,复制函数,释放函数和比较函数,还有链表长度,因为包含了前两个节点,找到表尾节点跟表头都是 O(1)的时间复杂度,还有节点数量,其实这个跟 SDS 是同一个做法,就是空间换时间,这也是写代码里比较常见的做法,以此让一些高频的操作提速。
字典也是个常用的数据结构,其实只是叫法不同,数据结构中叫 hash 散列,Java 中叫 Map,PHP 中是数组 array,Python 中也叫字典 dict,因为纯 C 语言本身不带这些数据结构,所以这也是个痛并快乐着的过程,享受 C 语言的高性能的同时也要接受它只提供了语言的基本功能的现实,各种轮子都需要自己造,redis 同样实现了自己的字典
下面来看看代码
typedef struct dictEntry { |
看了下这个 2.2 版本的代码跟最新版的其实也差的不是很多,所以还是照旧用老代码,可以看到上面四个结构体中,其实只有三个是存储数据用的,dictType 是用来放操作函数的,那么三个存放数据的结构体分别是干嘛的,这时候感觉需要一个图来说明比较好,稍等,我去画个图~
这个图看着应该比较清楚这些都是用来干嘛的了,dict 是我们的主体结构,它有一个指向 dictType 的指针,这里面包含了字典的操作函数,然后是一个私有数据指针,接下来是一个 dictht 的数组,包含两个dictht,这个就是用来存数据的了,然后是 rehashidx 表示重哈希的状态,当是-1 的时候表示当前没有重哈希,iterators 表示正在遍历的迭代器的数量。
首先说说为啥需要有两个 dictht,这是因为字典 dict 这个数据结构随着数据量的增减,会需要在中途做扩容或者缩容操作,如果只有一个的话,对它进行扩容缩容时会影响正常的访问和修改操作,或者说保证正常查询,修改的正确性会比较复杂,并且因为需要高效利用空间,不能一下子申请一个非常大的空间来存很少的数据。当 dict 中 dictht 中的数据量超过 size 的时候负载就超过了 1,就需要进行扩容,这里的其实跟 Java 中的 HashMap 比较类似,超过一定的负载之后进行扩容。这里为啥 size 会超过 1 呢,可能有部分不了解这类结构的同学会比较奇怪,其实就是上图中画的,在数据结构中对于散列的冲突有几类解决方法,比如转换成链表,二次散列,找下个空槽等,这里就使用了链表法,或者说拉链法。当一个新元素通过 hashFunction 得出的 key 跟 sizemask 取模之后的值相同了,那就将其放在原来的节点之前,变成链表挂在数组 dictht.table下面,放在原有节点前是考虑到可能会优先访问。
忘了说明下 dictht 跟 dictEntry 的关系了,dictht 就是个哈希表,它里面是个dictEntry 的二维数组,而 dictEntry 是个包含了 key-value 结构之外还有一个 next 指针,因此可以将哈希冲突的以链表的形式保存下来。
在重点说下重哈希,可能同样写 Java 的同学对这个比较有感觉,跟 HashMap 一样,会以 2 的 N 次方进行扩容,那么扩容的方法就会比较简单,每个键重哈希要不就在原来这个槽,要不就在原来的槽加原 dictht.size 的位置;然后是重头戏,具体是怎么做扩容呢,其实这里就把第二个 ht 用上了,其实这两个hashtable 的具体作用有点类似于 jvm 中的两个 survival 区,但是又不全一样,因为 redis 在扩容的时候是采用的渐进式地重哈希,什么叫渐进式的呢,就是它不是像 jvm 那种标记复制的模式直接将一个 eden 区和原来的 survival 区存活的对象复制到另一个 survival 区,而是在每一次添加,删除,查找或者更新操作时,都会额外的帮忙搬运一部分的原 dictht 中的数据,这里会根据 rehashidx 的值来判断,如果是-1 表示并没有在重哈希中,如果是 0 表示开始重哈希了,然后rehashidx 还会随着每次的帮忙搬运往上加,但全部被搬运完成后 rehashidx 又变回了-1,又可以扯到Java 中的 Concurrent HashMap, 他在扩容的时候也使用了类似的操作。
typedef struct intset { |
一眼看,为啥整型还需要编码,然后 int8_t 怎么能存下大整形呢,带着这些疑问,我们一步步分析下去,这里的编码其实指的是这个整型集合里存的究竟是多大的整型,16 位,还是 32 位,还是 64 位,结构体下面的宏定义就是表示了 encoding 的可能取值,INTSET_ENC_INT16 表示每个元素用2个字节存储,INTSET_ENC_INT32 表示每个元素用4个字节存储,INTSET_ENC_INT64 表示每个元素用8个字节存储。因此,intset中存储的整数最多只能占用64bit。length 就是正常的表示集合中元素的数量。最奇怪的应该就是这个 contents 了,是个 int8_t 的数组,那放毛线数据啊,最小的都有 16 位,这里我在看代码和《redis 设计与实现》的时候也有点懵逼,后来查了下发现这是个比较取巧的用法,这里我用自己的理解表述一下,先看看 8,16,32,64 的关系,一眼看就知道都是 2 的 N 次,并且呈两倍关系,而且 8 位刚好一个字节,所以呢其实这里的contents 不是个常规意义上的 int8_t 类型的数组,而是个柔性数组。看下 wiki 的定义
Flexible array members1 were introduced in the C99 standard of the C programming language (in particular, in section §6.7.2.1, item 16, page 103).2 It is a member of a struct, which is an array without a given dimension. It must be the last member of such a struct and it must be accompanied by at least one other member, as in the following example:
struct vectord { |
在初始化这个 intset 的时候,这个contents数组是不占用空间的,后面的反正用到了申请,那么这里就有一个问题,给出了三种可能的 encoding 值,他们能随便换吗,显然不行,首先在 intset 中数据的存放是有序的,这个有部分原因是方便二分查找,然后存放数据其实随着数据的大小不同会有一个升级的过程,看下图
新创建的intset只有一个header,总共8个字节。其中encoding = 2, length = 0, 类型都是uint32_t,各占 4 字节,添加15, 5两个元素之后,因为它们是比较小的整数,都能使用2个字节表示,所以encoding不变,值还是2,也就是默认的 INTSET_ENC_INT16,当添加32768的时候,它不再能用2个字节来表示了(2个字节能表达的数据范围是-215~215-1,而32768等于215,超出范围了),因此encoding必须升级到INTSET_ENC_INT32(值为4),即用4个字节表示一个元素。在添加每个元素的过程中,intset始终保持从小到大有序。与ziplist类似,intset也是按小端(little endian)模式存储的(参见维基百科词条Endianness)。比如,在上图中intset添加完所有数据之后,表示encoding字段的4个字节应该解释成0x00000004,而第4个数据应该解释成0x00008000 = 32768
跳表是个在我们日常的代码中不太常用到的数据结构,相对来讲就没有像数组,链表,字典,散列,树等结构那么熟悉,所以就从头开始分析下,首先是链表,跳表跟链表都有个表字(太硬扯了我🤦♀️),注意这是个有序链表
如上图,在这个链表里如果我要找到 23,是不是我需要从3,5,9开始一直往后找直到找到 23,也就是说时间复杂度是 O(N),N 的一次幂复杂度,那么我们来看看第二个
这个结构跟原先有点不一样,它给链表中偶数位的节点又加了一个指针把它们链接起来,这样子当我们要寻找 23 的时候就可以从原来的一个个往下找变成跳着找,先找到 5,然后是 10,接着是 19,然后是 28,这时候发现 28 比 23 大了,那我在退回到 19,然后从下一层原来的链表往前找,
这里毛估估是不是前面的节点我就少找了一半,有那么点二分法的意思。
前面的其实是跳表的引子,真正的跳表其实不是这样,因为上面的其实有个比较大的问题,就是插入一个元素后需要调整每个元素的指针,在 redis 中的跳表其实是做了个随机层数的优化,因为沿着前面的例子,其实当数据量很大的时候,是不是层数越多,其查询效率越高,但是随着层数变多,要保持这种严格的层数规则其实也会增大处理复杂度,所以 redis 插入每个元素的时候都是使用随机的方式,看一眼代码
/* ZSETs use a specialized version of Skiplists */ |
忘了说了,redis 是把 skiplist 跳表用在 zset 里,zset 是个有序的集合,可以看到 zskiplist 就是个跳表的结构,里面用 header 保存跳表的表头,tail 保存表尾,还有长度和最大层级,具体的跳表节点元素使用 zskiplistNode 表示,里面包含了 sds 类型的元素值,double 类型的分值,用来排序,一个 backward 后向指针和一个 zskiplistLevel 数组,每个 level 包含了一个前向指针,和一个 span,span 表示的是跳表前向指针的跨度,这里再补充一点,前面说了为了灵活这个跳表的新增修改,redis 使用了随机层高的方式插入新节点,但是如果所有节点都随机到很高的层级或者所有都很低的话,跳表的效率优势就会减小,所以 redis 使用了个小技巧,贴下代码
|
当随机值跟0xFFFF进行与操作小于ZSKIPLIST_P * 0xFFFF时才会增大 level 的值,因此保持了一个相对递减的概率
可以简单分析下,当 random() 的值小于 0xFFFF 的 1/4,才会 level + 1,就意味着当有 1 - 1/4也就是3/4的概率是直接跳出,所以一层的概率是3/4,也就是 1-P,二层的概率是 P*(1-P),三层的概率是 P² * (1-P) 依次递推。
/* The actual Redis Object */ |
主体结构就是这个 redisObject,
/* quicklistNode is a 32 byte struct describing a ziplist for a quicklist. |
粗略看下,quicklist 里有 head,tail, quicklistNode里有 prev,next 指针,是不是有链表的基本轮廓了,那么为啥这玩意要称为快表呢,快在哪,关键就在这个unsigned char *zl;zl 是不是前面又看到过,就是 ziplist ,这是什么鬼,链表里用压缩表,这不套娃么,先别急,回顾下前面说的 ziplist,ziplist 有哪些特点,内存利用率高,可以从表头快速定位到尾节点,节点可以从后往前找,但是有个缺点,就是从中间插入的效率比较低,需要整体往后移,这个其实是普通数组的优化版,但还是有数组的一些劣势,所以要真的快,是不是可以将链表跟数组真的结合起来。
这里有两个 redis 的配置参数,list-max-ziplist-size 和 list-compress-depth,先来说第一个,既然快表是将链表跟压缩表数组结合起来使用,那么具体怎么用呢,比如我有一个 10 个元素的 list,那具体怎么放,每个 quicklistNode 里放多大的 ziplist,假如每个快表节点的 ziplist 只放一个元素,那么其实这就退化成了一个链表,如果 10 个元素放在一个 quicklistNode 的 ziplist 里,那就退化成了一个 ziplist,所以有了这个 list-max-ziplist-size,而且它还比较牛,能取正负值,当是正值时,对应的就是每个 quicklistNode 的 ziplist 中的元素个数,比如配置了 list-max-ziplist-size = 5,那么我刚才的 10 个元素的 list 就是一个两个 quicklistNode 组成的快表,每个 quicklistNode 中的 ziplist 包含了五个元素,当 list-max-ziplist-size取负值的时候,它限制了 ziplist 的字节数
size_t offset = (-fill) - 1; |
这个 fill 就是传进来的 list-max-ziplist-size, 具体对应的就是
quicklist->fill = -2;list-compress-depth这个参数呢是用来配置压缩的,等等压缩是为啥,不是里面已经是压缩表了么,大牛们就是为了性能殚精竭虑,这里考虑到的是一个场景,一般状况下,list 都是两端的访问频率比较高,那么是不是可以对中间的数据进行压缩,那么这个参数就是用来表示
/* depth of end nodes not to compress;0=off */ |
简单说下插入元素的过程
/* Wrapper to allow argument-based switching between HEAD/TAIL pop */ |
前面第一步先根据插入的是头还是尾选择不同的 push 函数,quicklistPushHead 或者 quicklistPushTail,举例分析下从头插入的 quicklistPushHead,先判断当前的 quicklistNode 节点还能不能允许再往 ziplist 里添加元素,如果可以就添加,如果不允许就新建一个 quicklistNode,然后调用 _quicklistInsertNodeBefore 将节点插进去,具体插入quicklist节点的操作类似链表的插入。
]]>The ziplist is a specially encoded dually linked list that is designed to be very memory efficient.
这是摘自 redis 源码中ziplist.c 文件的注释,也说明了原因,它的大概结构是这样子
<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend> |
其中<zlbytes>表示 ziplist 占用的字节总数,类型是uint32_t,32 位的无符号整型,当然表示的字节数也包含自己本身占用的 4 个<zltail> 类型也是是uint32_t,表示ziplist表中最后一项(entry)在ziplist中的偏移字节数。<zltail>的存在,使得我们可以很方便地找到最后一项(不用遍历整个ziplist),从而可以在ziplist尾端快速地执行push或pop操作。<uint16_t zllen> 表示ziplist 中的数据项个数,因为是 16 位,所以当数量超过所能表示的最大的数量,它的 16 位全会置为 1,但是真实的数量需要遍历整个 ziplist 才能知道<entry>是具体的数据项,后面解释<zlend> ziplist 的最后一个字节,固定是255。
再看一下<entry>中的具体结构,
<prevlen> <encoding> <entry-data> |
首先这个<prevlen>有两种情况,一种是前面的元素的长度,如果是小于等于 253的时候就用一个uint8_t 来表示前一元素的长度,如果大于的话他将占用五个字节,第一个字节是 254,即表示这个字节已经表示不下了,需要后面的四个字节帮忙表示<encoding>这个就比较复杂,把源码的注释放下面先看下
* |00pppppp| - 1 byte |
首先如果 encoding 的前两位是 00 的话代表这个元素是个 6 位的字符串,即直接将数据保存在 encoding 中,不消耗额外的<entry-data>,如果前两位是 01 的话表示是个 14 位的字符串,如果是 10 的话表示encoding 块之后的四个字节是存放字符串类型的数据,encoding 的剩余 6 位置 0。
如果 encoding 的前两位是 11 的话表示这是个整型,具体的如果后两位是00的话,表示后面是个2字节的 int16_t 类型,如果是01的话,后面是个4字节的int32_t,如果是10的话后面是8字节的int64_t,如果是 11 的话后面是 3 字节的有符号整型,这些都要最后 4 位都是 0 的情况噢
剩下当是11111110时,则表示是一个1 字节的有符号数,如果是 1111xxxx,其中xxxx在0000 到 1101 表示实际的 1 到 13,为啥呢,因为 0000 前面已经用过了,而 1110 跟 1111 也都有用了。
看个具体的例子(上下有点对不齐,将就看)
[0f 00 00 00] [0c 00 00 00] [02 00] [00 f3] [02 f6] [ff] |
第一部分代表整个 ziplist 有 15 个字节,zlbytes 自己占了 4 个 zltail 表示最后一个元素的偏移量,第 13 个字节起,zllen 表示有 2 个元素,第一个元素是00f3,00表示前一个元素长度是 0,本来前面就没元素(不过不知道这个能不能优化这一字节),然后是 f3,换成二进制就是11110011,对照上面的注释,是落在|1111xxxx|这个类型里,注意这个其实是用 0001 到 1101 也就是 1到 13 来表示 0到 12,所以 f3 应该就是 2,第一个元素是 2,第二个元素呢,02 代表前一个元素也就是刚才说的这个,占用 2 字节,f6 展开也是刚才的类型,实际是 5,ff 表示 ziplist 的结尾,所以这个 ziplist 里面是两个元素,2 跟 5
| Policy | Description |
|---|---|
| noeviction 不逐出 | Returns an error if the memory limit has been reached when trying to insert more data,插入更多数据时,如果内存达到上限了,返回错误 |
| allkeys-lru 所有的 key 使用 lru 逐出 | Evicts the least recently used keys out of all keys 在所有 key 中逐出最近最少使用的 |
| allkeys-lfu 所有的 key 使用 lfu 逐出 | Evicts the least frequently used keys out of all keys 在所有 key 中逐出最近最不频繁使用的 |
| allkeys-random 所有的 key 中随机逐出 | Randomly evicts keys out of all keys 在所有 key 中随机逐出 |
| volatile-lru | Evicts the least recently used keys out of all keys with an “expire” field set 在设置了过期时间的 key 空间 expire 中使用 lru 策略逐出 |
| volatile-lfu | Evicts the least frequently used keys out of all keys with an “expire” field set 在设置了过期时间的 key 空间 expire 中使用 lfu 策略逐出 |
| volatile-random | Randomly evicts keys with an “expire” field set 在设置了过期时间的 key 空间 expire 中随机逐出 |
| volatile-ttl | Evicts the shortest time-to-live keys out of all keys with an “expire” field set.在设置了过期时间的 key 空间 expire 中逐出更早过期的 |
而在这其中默认使用的策略是 volatile-lru,对 lru 跟 lfu 想有更多的了解可以看下我之前的文章redis系列介绍八-淘汰策略
]]>redis 是如何过期缓存的,可以猜测下,最无脑的就是每个设置了过期时间的 key 都设个定时器,过期了就删除,这种显然消耗太大,清理地最及时,还有的就是 redis 正在采用的懒汉清理策略和定期清理
懒汉策略就是在使用的时候去检查缓存是否过期,比如 get 操作时,先判断下这个 key 是否已经过期了,如果过期了就删掉,并且返回空,如果没过期则正常返回
主要代码是
/* This function is called when we are going to perform some operation |
这里有几点要注意的,第一是当惰性删除时会根据lazyfree_lazy_expire这个参数去判断是执行同步删除还是异步删除,另外一点是对于 slave,是不需要执行的,因为会在 master 过期时向 slave 发送 del 指令。
光采用这个策略会有什么问题呢,假如一些key 一直未被访问,那这些 key 就不会过期了,导致一直被占用着内存,所以 redis 采取了懒汉式过期加定期过期策略,定期策略是怎么执行的呢
/* This function handles 'background' operations we are required to do |
执行定期清除分成两种类型,快和慢,分别由beforeSleep和databasesCron调用,快版有两个限制,一个是执行时长由ACTIVE_EXPIRE_CYCLE_FAST_DURATION限制,另一个是执行间隔是 2 倍的ACTIVE_EXPIRE_CYCLE_FAST_DURATION,另外这还可以由配置的server.active_expire_effort参数来控制,默认是 1,最大是 10
onfig_cycle_fast_duration = ACTIVE_EXPIRE_CYCLE_FAST_DURATION + |
然后会从一定数量的 db 中找出一定数量的带过期时间的 key(保存在 expires中),这里的数量是由
config_keys_per_loop = ACTIVE_EXPIRE_CYCLE_KEYS_PER_LOOP + |
这里还有一个额外的退出条件,如果当前数据库的抽样结果已经达到我们所允许的过期 key 百分比,则下次不再处理当前 db,继续处理下个 db
]]>说完了过期策略再说下淘汰策略,redis 使用的策略是近似的 lru 策略,为什么是近似的呢,先来看下什么是 lru,看下 wiki 的介绍
,图中一共有四个槽的存储空间,依次访问顺序是 A B C D E D F,
当第一次访问 D 时刚好占满了坑,并且值是 4,这个值越小代表越先被淘汰,当 E 进来时,看了下已经存在的四个里 A 是最小的,代表是最早存在并且最早被访问的,那就先淘汰它了,E 占领了 A 的位置,并设置值为 4,然后又访问 D 了,D 已经存在了,不过又被访问到了,得更新值为 5,然后是 F 进来了,这时 B 是最老的且最近未被访问,所以就淘汰它了。以上是一个 lru 的简要说明,但是 redis 没有严格按照这个去执行,理由跟前面过期策略一致,最严格的过期策略应该是每个 key 都有对应的定时器,当超时时马上就能清除,但是问题是这样的cpu 消耗太大,所换来的内存效率不太值得,淘汰策略也是这样,类似于上图,要维护所有 key 的一个有序 lru 值,并且遍历将最小的淘汰,redis 采用的是抽样的形式,最初的实现方式是随机从 dict 抽取 5 个 key,淘汰一个 lru 最小的,这样子勉强能达到淘汰的目的,但是效果不是特别好,后面在 redis 3.0开始,将随机抽取改成了维护一个 pool,pool 的大小默认是 16,每次放入的都是按lru 值有序排列好,每一次放入的必须是 lru小于 pool 中最小的 lru 才允许放入,直到放满,后面再有新的就会将大的踢出。
redis 针对这个策略的改进做了一个实验,这里借用下图
首先背景是这图中的所有点都对应一个 redis 的 key,灰色部分加入后被顺序访问过一遍,然后又加入了绿色部分,那么按照理论的 lru 算法,应该是图左上中,浅灰色部分全都被淘汰,那么对比来看看图右上,左下和右下,左下表示 2.8 版本就是随机抽样 5 个 key,淘汰其中 lru 最小的一个,发现是灰色和浅灰色的都有被淘汰的,右下的 3.0 版本抽样数量不变的情况下,稍好一些,当 3.0 版本的抽样数量调整成 10 后,已经较为接近理论上的 lru 策略了,通过代码来简要分析下
typedef struct redisObject { |
对于 lru 策略来说,lru 字段记录的就是redisObj 的LRU time,
redis 在访问数据时,都会调用lookupKey方法
/* Low level key lookup API, not actually called directly from commands |
redis 处理命令是在这里processCommand
/* If this function gets called we already read a whole |
这里只摘了部分,当需要清理内存时就会调用, 然后调用了freeMemoryIfNeededAndSafe
/* This is a wrapper for freeMemoryIfNeeded() that only really calls the |
这里就是根据具体策略去淘汰 key,首先是要往 pool 更新 key,更新key 的方法是evictionPoolPopulate
void evictionPoolPopulate(int dbid, dict *sampledict, dict *keydict, struct evictionPoolEntry *pool) { |
Redis随机选择maxmemory_samples数量的key,然后计算这些key的空闲时间idle time,当满足条件时(比pool中的某些键的空闲时间还大)就可以进pool。pool更新之后,就淘汰pool中空闲时间最大的键。
estimateObjectIdleTime用来计算Redis对象的空闲时间:
/* Given an object returns the min number of milliseconds the object was never |
空闲时间第一种是 lurclock 大于对象的 lru,那么就是减一下乘以精度,因为 lruclock 有可能是已经预生成的,所以会可能走下面这个
上面介绍了LRU 的算法,但是考虑一种场景
~~~~~A~~~~~A~~~~~A~~~~A~~~~~A~~~~~A~~| |
可以发现,当采用 lru 的淘汰策略的时候,D 是最新的,会被认为是最值得保留的,但是事实上还不如 A 跟 B,然后 antirez 大神就想到了LFU (Least Frequently Used) 这个算法, 显然对于上面的四个 key 的访问频率,保留优先级应该是 B > A > C = D
那要怎么来实现这个 LFU 算法呢,其实像LRU,理想的情况就是维护个链表,把最新访问的放到头上去,但是这个会影响访问速度,注意到前面代码的应该可以看到,redisObject 的 lru 字段其实是两用的,当策略是 LFU 时,这个字段就另作他用了,它的 24 位长度被分成两部分
16 bits 8 bits |
前16位字段是最后一次递减时间,因此Redis知道 上一次计数器递减,后8位是 计数器 counter。
LFU 的主体策略就是当这个 key 被访问的次数越多频率越高他就越容易被保留下来,并且是最近被访问的频率越高。这其实有两个事情要做,一个是在访问的时候增加计数值,在一定长时间不访问时进行衰减,所以这里用了两个值,前 16 位记录上一次衰减的时间,后 8 位记录具体的计数值。
Redis4.0之后为maxmemory_policy淘汰策略添加了两个LFU模式:
volatile-lfu:对有过期时间的key采用LFU淘汰策略allkeys-lfu:对全部key采用LFU淘汰策略
还有2个配置可以调整LFU算法:
lfu-log-factor 10 |
updateLFU 这个其实个入口,调用了两个重要的方法
/* Update LFU when an object is accessed. |
首先来看看LFUDecrAndReturn,这个方法的作用是根据上一次衰减时间和系统配置的 lfu-decay-time 参数来确定需要将 counter 减去多少
/* If the object decrement time is reached decrement the LFU counter but |
然后是加,调用了LFULogIncr
/* Logarithmically increment a counter. The greater is the current counter value |
大概的变化速度可以参考
+--------+------------+------------+------------+------------+------------+ |
简而言之就是 lfu_log_factor 越大变化的越慢
总结一下,redis 实现了近似的 lru 淘汰策略,通过增加了淘汰 key 的池子(pool),并且增大每次抽样的 key 的数量来将淘汰效果更进一步地接近于 lru,这是 lru 策略,但是对于前面举的一个例子,其实 lru 并不能保证 key 的淘汰就如我们预期,所以在后期又引入了 lfu 的策略,lfu的策略比较巧妙,复用了 redis 对象的 lru 字段,并且使用了factor 参数来控制计数器递增的速度,防止 8 位的计数器太早溢出。
]]>之前其实写过redis的过期的一些原理,这次主要是记录下,一些使用上的概念,主要是redis使用的过期策略是懒过期和定时清除,懒过期的其实比较简单,即是在key被访问的时候会顺带着判断下这个key是否已过期了,如果已经过期了,就不返回了,但是这种策略有个漏洞是如果有些key之后一直不会被访问了,就等于沉在池底了,所以需要有一个定时的清理机制,去从设置了过期的key池子(expires)里随机地捞key,具体的策略我们看下官网的解释
从池子里随机获取20个key,将其中过期的key删掉,如果这其中有超过25%的key已经过期了,那就再来一次,以此保持过期的key不超过25%(左右),并且这个定时策略可以在redis的配置文件
Redis calls an internal function to perform many background tasks, like |
可以配置这个hz的值,代表的含义是每秒的执行次数,默认是10,其实也用了hz的普遍含义。有兴趣可以看看之前写的一篇文章redis系列介绍七-过期策略
]]>fn main() { |
这里其实我们就需要关注 s 的存在性,代码的逻辑合理性就需要额外去维护,此时我们就可以用切片
let s = String::from("hello world") |
其实跟 Python 的list 之类的语法有点类似,当然里面还有些语法糖,比如可以直接用省略后面的数字表示直接引用到结尾
let hello = &s[0..]; |
甚至再进一步
let hello = &s[..]; |
使用了切片之后
fn first_word(s: &String) -> &str { |
那再执行 main 函数的时候就会抛错,因为 word 还是个切片,需要保证 s 的有效性,并且其实我们可以将函数申明成
fn first_word(s: &str) -> &str { |
这样就既能处理&String 的情况,就是当成完整字符串的切片,也能处理普通的切片。
其他类型的切片
let a = [1, 2, 3, 4, 5]; |
简单记录下,具体可以去看看这本书
]]>此时我们就可以用引用来解决这个问题
fn main() { |
这里的&符号就是引用的语义,它们允许你在不获得所有权的前提下使用值
由于引用不持有值的所有权,所以当引用离开当前作用域时,它指向的值也不会被丢弃
而当我们尝试对引用的字符串进行修改时
fn main() { |
就会有以下报错,
其实也很容易发现,毕竟没有 mut 指出这是可变引用,同时需要将 s1 改成 mut 可变的
fn main() { |
再看一个例子
fn main() { |
这个例子在书里是会报错的,因为同时存在一个以上的可变引用,但是在我运行的版本里前面这段没有报错,只有当我真的要去更改的时候
fn main() { |

这里可能就是具体版本在实现上的一个差异,我用的 rustc 是 1.44.0 版本
其实上面的主要是由 rust 想要避免这类多重可变更导致的异常问题,总结下就是三个点
还有一点需要注意的就是悬垂引用
fn main() { |
这里可以看到其实在 dangle函数返回后,这里的 s 理论上就离开了作用域,但是由于返回了 s 的引用,在 main 函数中就会拿着这个引用,就会出现如下错误
最后总结下
然后看个案例
let x = 5; |
这个其实有两种,一般可以认为比较多实现的会使用 copy on write 之类的,先让两个都指向同一个快 5 的存储,在发生变更后开始正式拷贝,但是涉及到内存处理的便利性,对于这类简单类型,可以直接拷贝
但是对于非基础类型
let s1 = String::from("hello"); |
有可能认为有两种内存分布可能
先看下 string 的内存结构
第一种可能是
第二种是
我们来尝试编译下
发现有这个错误,其实在 rust 中let y = x这个行为的实质是移动,在赋值给 y 之后 x 就无效了
这样子就不会造成脱离作用域时,对同一块内存区域的二次释放,如果需要复制,可以使用 clone 方法
let s1 = String::from("hello"); |
这里其实会有点疑惑,为什么前面的x, y 的行为跟 s1, s2 的不一样,其实主要是基本类型和 string 这类的不定大小的类型的内存分配方式不同,x, y这类整型可以直接确定大小,可以直接在栈上分配,而像 string 和其他的变体结构体,其大小都是不能在编译时确定,所以需要在堆上进行分配
工作中学习使用了一下Spark做数据分析,主要是用spark的python接口,首先是pyspark.SparkContext(appName=xxx),这是初始化一个Spark应用实例或者说会话,不能重复,
返回的实例句柄就可以调用textFile(path)读取文本文件,这里的文本文件可以是HDFS上的文本文件,也可以普通文本文件,但是需要在Spark的所有集群上都存在,否则会
读取失败,parallelize则可以将python生成的集合数据读取后转换成rdd(A Resilient Distributed Dataset (RDD),一种spark下的基本抽象数据集),基于这个RDD就可以做
数据的流式计算,例如map reduce,在Spark中可以非常方便地实现
textFile = sc.parallelize([(1,1), (2,1), (3,1), (4,1), (5,1),(1,1), (2,1), (3,1), (4,1), (5,1)]) |
(3, 2) |
比如在请求中参数就使用 httpRequest(HttpServletRequest request, HttpServletResponse response)
然后在返回的时候就使用 response.getOutputStream().write(result),而如果是要返回 json 形式的话就可以像这个文章说明的
链接
Employee employee = new Employee(1, "Karan", "IT", 5000); |
一开始我也是这么一搜就用了,后来发现返回的一直是乱码,仔细看了下发现了个问题,就是这个 response 设置 contentType 是在getWriter之后的,这样自然就不会起作用了,所以要在设置 setContentType 和 setCharacterEncoding 之后再 getWriter,之后就可以正常返回了。
|
这个 ApplicationEvent 其实也比较简单,内部就一个 Object 类型的 source,可以自行扩展,我们在自定义的这个 Event 里加了个 Message ,只是简单介绍下使用
public abstract class ApplicationEvent extends EventObject { |
然后就是事件生产者和监听消费者
|
这里的 ApplicationEventPublisher 是 Spring 的方法接口
|
具体的是例如 org.springframework.context.support.AbstractApplicationContext#publishEvent(java.lang.Object, org.springframework.core.ResolvableType) 中的实现,后面可以展开讲讲
事件监听者:
|
这里的也是 spring 的一个方法接口
|
然后简单包个请求
|

就能看到接收到消息了。
RequestMappingHandlerMapping 的继承关系org.springframework.beans.factory.InitializingBean 这个接口,然后这个 InitializingBean 提供了 org.springframework.beans.factory.InitializingBean#afterPropertiesSet 接口,可以在 bean 初始化后做一些属性设置等,public void afterPropertiesSet() { |
父类是 org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#afterPropertiesSet
具体代码很简略,就是初始化 HandlerMethod
|
也就是调用了 org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#initHandlerMethods
protected void initHandlerMethods() { |
然后就是调用 org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#processCandidateBean
protected void processCandidateBean(String beanName) { |
先是获取的 beanType,在判断 beanType 是不是 Handler,通过方法 org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping#isHandler
|
就很简单,判断是不是有 Controller 注解或者 RequestMapping 注解
然后就是判断 HandlerMethod 了,调用了 org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#detectHandlerMethods
protected void detectHandlerMethods(Object handler) { |
前面先通过 getMappingForMethod 找出有 Mapping 的方法,
|
|
然后再是对 Method 循环调用 org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#registerHandlerMethod
可以看到就是上一篇的 org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#mappingRegistry 去存储映射信息
protected void registerHandlerMethod(Object handler, Method method, T mapping) { |
最后是真的注册逻辑
public void register(T mapping, Object handler, Method method) { |
底层的存储就是上一篇说的 mappingLookup 来存储信息
]]>org.springframework.context.support.AbstractApplicationContext#refreshtry { |
跟进去其实本身是啥都不做的,由具体的实现类子类去做各自的处理org.springframework.context.support.AbstractApplicationContext#onRefresh
/** |
看具体的实现类里就有我们的主角org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext#onRefresh
protected void onRefresh() { |
具体的就是一些前置处理org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext#createWebServer
private void createWebServer() { |
初始的 webServer 和 servletContext 都是 null,需要进行初始化
先是获取 WebServer 工厂,org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext#getWebServerFactory
protected ServletWebServerFactory getWebServerFactory() { |
获取了类型是 ServletWebServerFactory 的 bean,然后再回来就是调用的接口方法org.springframework.boot.web.servlet.server.ServletWebServerFactory#getWebServer
根据具体的 factory 来生成对应的譬如 tomcat 的 factory,org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory#getWebServer
|

最后一行就是创建 TomcatWebServer,org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory#getTomcatWebServer
/** |
这里面就开始 new 了一个 TomcatWebServer,org.springframework.boot.web.embedded.tomcat.TomcatWebServer#TomcatWebServer(org.apache.catalina.startup.Tomcat, boolean)
public TomcatWebServer(Tomcat tomcat, boolean autoStart) { |
再调用里面的初始化方法,org.springframework.boot.web.embedded.tomcat.TomcatWebServer#initialize
private void initialize() throws WebServerException { |
然后就是启动 server,后面可以继续看这个启动 TomcatServer 内部的逻辑
]]>
|
200 状态就很简单,如果想做跳转可以使用 302 并设置 location
|
这里如果设置了 302,但没设置跳转 location,就是 302 found
int SC_MOVED_TEMPORARILY = 302; |
而如果是 301 跳转,代表原地址不可用了,永久跳转
|
|
这样的设置就能成功设定 cookie,而随着目前的浏览器 cookie 策略,如果要跳转后设置的话,估计是会越来越难,包括
response.addHeader("Set-Cookie", "a=b; domain=baidu.com; SameSite=none;Secure"); |
这样的方式也没法实现。
]]>RequestMappingHandlerMapping mapping = appContext.getBean(RequestMappingHandlerMapping.class); |
逐行来解析下,第一行就是从上下文中获取 RequestMappingHandlerMapping 这个 bean,
然后调用了 getHandlerMethods,
这里面具体执行了
public Map<T, HandlerMethod> getHandlerMethods() { |
前后加了锁,重要的就是从 mappingRegistry 中获取 mappings, 这里获取的就是org.springframework.web.servlet.handler.AbstractHandlerMethodMapping.MappingRegistry#getMappings 具体的代码
public Map<T, HandlerMethod> getMappings() { |
而这个 mappingLookup 再来看下
class MappingRegistry { |
可以看到就是在 MappingRegistry 中的一个变量,至于这个变量是怎么来的,简单的考虑下 springboot 处理请求的流程,就是从 Mapping 去找到对应的 Handler,所以就需要提前将这个对应关系存到这个变量里,
具体可以看这 org.springframework.web.servlet.handler.AbstractHandlerMethodMapping.MappingRegistry#register
public void register(T mapping, Object handler, Method method) { |
就是在这里会把 mapping 和 handleMethod 对应关系存进去
这里拿的是上面的 map 里的 key,也就是 RequestMappingInfo 也就是 org.springframework.web.servlet.mvc.method.RequestMappingInfo
而真的 url 就存在 org.springframework.web.servlet.mvc.condition.PatternsRequestCondition
最终这里面的patterns就是我们要的路径
public class PatternsRequestCondition extends AbstractRequestCondition<PatternsRequestCondition> { |
写到这下一篇是不是可以介绍下 mapping 的具体注册逻辑
]]>org.springframework.web.servlet.DispatcherServlet#doService
protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception { |
然后就是调用org.springframework.web.servlet.DispatcherServlet#doDispatch
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception { |
看下这里的逻辑
|
可以看到有这些 HandlerMapping
而这里面就是前面提到过的org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping
从这就能找到具体的 Handlercom.nicksxs.spbdemo.controller.DemoController#test()
这就是我简单的示例代码
|
下一步是再获取处理器的适配器,org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter
protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException { |
正好这个适配器是调用的父类的 supports 方法
|
而我这个com.nicksxs.spbdemo.controller.DemoController#test()
就是个包装好的 HandlerMethod
然后就是调用 ha 的 handle 方法,也是通过模板方法,实际调用的是org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter#handle
|
然后调用org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#handleInternal
|
继续调用org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#invokeHandlerMethod
|
稍微再看一眼
第一步是org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter#createInvocableHandlerMethod
protected ServletInvocableHandlerMethod createInvocableHandlerMethod(HandlerMethod handlerMethod) { |
第二步是org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod#ServletInvocableHandlerMethod(org.springframework.web.method.HandlerMethod)
public ServletInvocableHandlerMethod(HandlerMethod handlerMethod) { |
第三步是org.springframework.web.method.support.InvocableHandlerMethod#InvocableHandlerMethod(org.springframework.web.method.HandlerMethod)
public InvocableHandlerMethod(HandlerMethod handlerMethod) { |
第四步是org.springframework.web.method.HandlerMethod#HandlerMethod(org.springframework.web.method.HandlerMethod)
protected HandlerMethod(HandlerMethod handlerMethod) { |
这是个继承关系,一直调用到最顶层的父类的构造方法,其实就是拷贝,然后继续调用org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod#invokeAndHandle
public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer, |
继续调用org.springframework.web.method.support.InvocableHandlerMethod#invokeForRequest
|
来到了最核心处
org.springframework.web.method.support.InvocableHandlerMethod#doInvoke
|
bind: Cannot assign requested address |
查了下这个问题,猜测是不是端口已经被占用了,查了下并不是,然后想到是不是端口是系统保留的,
sysctl -a |grep port_range |
结果中
net.ipv4.ip_local_port_range = 50000 65000 -----意味着50000~65000端口可用 |
发现也不是,没有限制,最后才查到这个原因是默认如果有 ipv6 的话会使用 ipv6 的地址做映射
所以如果是命令连接做端口转发的话,
ssh -4 -L 11234:localhost:1234 x.x.x.x |
使用-4来制定通过 ipv4 地址来做映射
如果是在 .ssh/config 中配置的话可以直接指定所有的连接都走 ipv4
Host * |
inet代表 ipv4,inet6代表 ipv6
AddressFamily 的所有取值范围是:”any”(默认)、”inet”(仅IPv4)、”inet6”(仅IPv6)。
另外此类问题还可以通过 ssh -v 来打印更具体的信息
Given a sorted integer array without duplicates, return the summary of its ranges.
For example, given [0,1,2,4,5,7], return ["0->2","4->5","7"].
每一个区间的起点nums[i]加上j是否等于nums[i+j]
参考
class Solution { |
WebSocket是HTML5开始提供的一种在单个TCP连接上进行全双工通讯的协议。WebSocket通信协议于2011年被IETF定为标准RFC 6455,WebSocketAPI被W3C定为标准。
,在web私信,im等应用较多。背景和优缺点可以参看wiki。
因为swoole官方还不支持windows,所以需要装下linux,之前都是用ubuntu,
这次就试一下centos7,还是满好看的,虽然虚拟机会默认最小安装,需要在安装
时自己选择带gnome的,当然最小安装也是可以的,只是最后需要改下防火墙。
然后是装下PHP,Nginx什么的,我是用Oneinstack,可以按需安装
给做这个的大大点个赞。
1.install via pecl
pecl install swoole |
2.install from source
sudo apt-get install php5-dev |
3.add extension
extension = swoole.so |
4.test extension
php -m | grep swoole |
如果存在就代表安装成功啦
实现代码看了这位仁兄的代码
还是贴一下代码
服务端:
//创建websocket服务器对象,监听0.0.0.0:9502端口 |
客户端:
|
做了个循环,将当前用户的消息发送给同时在线的其他用户,比较简陋,如下图
user1:
user2:

user3:

systemtap-sdt-dev 这个包,--enable-dtrace 的php版本
|
这其实主要是为了触发系统调用
然后重点就是systemtap的脚本,它有点类似于c的代码,结构主要是 “事件” - “处理器”
比如我监听到了php发起了一个系统调用,那这个时候我想把它记录下来,打印日志这种
probe syscall.* |
这里就是针对所有的系统调用,如果是由php发起调用,那就打印出来pid和系统调用的名字(name就是这里的系统调用名字)
syscall.system_call 只是其中一类事件
还有对虚拟文件系统的操作 vfs.file_operation
内核的方法调用 kernel.function("function")
比如 probe kernel.function("*@net/socket.c") { }
还有可以是内核的一些追踪点kernel.trace("tracepoint")
比如 kernel.trace("kfree_skb") 这个表示每次当内核中的network buffer被释放的时候触发
还有的是时间时间timer events
比如
probe timer.s(4) |
每4秒打印一个 hello world
还有这些
timer.ms(milliseconds) |
最常规的一类就是打印信息了printf ( ) Statements
这个跟c语言也很像,可以用%s 跟 %d 作为占位符来填充字符串和数字
然后就是一些定义好的取值方法execname() (a string with the executable name)
就比如刚才的php,
线程id
tid() |
用户id
uid() |
比如系统调用就直接用 name
还有很多可以研究,第一篇学习就先到这里
tail filename.log |
这种,可以看到日志文件的最后10行
我们一般会使用
tail -f filename.log |
可以用 -f来看到后续新生成的日志,可以用来观察是否有新增的异常日志或者是否有没有按预期打印新的日志
然后对于我们对输出的日志行数有具体要求的
tail -f -n 100 filename.log |
可以用 -n 参数,可以指定显示行数,比如想要显示100行
而有一个技巧就是之前看到别的同学用过
tail -100f filename.log |
可以和上面产生一样的效果
这样可以少输几个字符,也算是一个偷懒小技巧了,如果对于经常需要登录服务器看日志的也算是个效率小窍门
只是这样子对于比如我只想看新增的特定内容的日志来说,好像还不行
这里我们就可以使用组合技,结合 tail 和 grep 命令
tail -f filename.log | grep something |
这样就可以关注 something 的新增了
wp_users 表,用 select 查询看下可以看到有用户的数据,如果是像我这样搭着玩的没有创建其他用户的话应该就只有一个用户,那我们的表里的用户数据就只会有一条,当然多条的话可以通过用户名来找UPDATE wp_users SET user_pass = MD5('123456') WHERE ID = 1; |
然后就能用自己的账户跟刚才更新的密码登录了。
]]>对于一块待整理区域,通过两个指针,free 在区域的起始端,scan 指针在区域的末端,free 指针从前往后知道找到空闲区域,scan 从后往前一直找到存活对象,当 free 指针未与 scan 指针交叉时,会给 scan 位置的对象特定位置标记上 free 的地址,即将要转移的地址,不过这里有个限制,这种整理算法一般会用于对象大小统一的情况,否则 free 指针扫描时还需要匹配scan 指针扫描到的存活对象的大小。
需要三次完整遍历堆区域
第一遍是遍历后将计算出所有对象的最终地址(转发地址)
第二遍是使用转发地址更新赋值器线程根以及被标记对象中的引用,该操作将确保它们指向对象的新位置
第三次遍历是relocate最终将存活对象移动到其新的目标位置
这个真的长见识了,
可以看到,原来是 A,B,C 对象引用了 N,这里会在第一次遍历的时候把这种引用反过来,让 N 的对象头部保存下 A 的地址,表示这类引用,然后在遍历到 B 的时候在链起来,到最后就会把所有引用了 N 对象的所有对象通过引线链起来,在第二次遍历的时候就把更新A,B,C 对象引用的 N 地址,并且移动 N 对象
这个一直提到过位图的实现方式,
可以看到在第一步会先通过位图标记,标记的方式是位图的每一位对应的堆内存的一个字(这里可能指的是 byte 吧),然后将一个存活对象的内存区域的第一个字跟最后一个字标记,这里如果在通过普通的方式就还需要一个地方在存转发地址,但是因为具体的位置可以通过位图算出来,也就不需要额外记录了
A more generic solution for running several HTTPS servers on a single IP address is TLS Server Name Indication extension (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently supported by most modern browsers, though may not be used by some old or special clients.
来源
机翻一下:在单个 IP 地址上运行多个 HTTPS 服务器的更通用的解决方案是 TLS 服务器名称指示扩展(SNI,RFC 6066),它允许浏览器在 SSL 握手期间传递请求的服务器名称,因此,服务器将知道哪个 它应该用于连接的证书。 目前大多数现代浏览器都支持 SNI,但某些旧的或特殊的客户端可能不使用 SNI。
首先我们需要确认 sni 已被支持
在实际的配置中就可以这样
stream { |
类似这样,但是这个理解是非常肤浅和不完善的,只是简单记忆下,后续再进行补充完整
还有一点就是我们在配置的时候经常配置就是 server_name,但是会看到直接在使用 ssl_server_name,
其实在listen 标识了 ssl, 对应的 ssl_server_name 就等于 server_name,不需要额外处理了。
public static void main(String[] args) { |
定义了个变量,用来表示100年的时间,然后计算出对应的时间戳
首先看下这个值
1094004736 |
如果对时间戳这些没概念的话,可能没发现有什么问题,但是好像也不对,乘以1000了,但是尾数是736
这个暂时我们先不管
public static void main(String[] args) { |
然后来看下
1094004736 |
然后我们去看下这个时间戳,按正常理解应该是2124年的8月31日
但实际是不对的,只是12天后,跟100年这个差距天差地别了,这是为啥呢,可能大佬一眼就看出来了这是类型转换问题,但是比如说我这么改
public static void main(String[] args) { |
或者
public static void main(String[] args) { |
会发现还是一样,依旧是错误的
简单来说,就在于类型转换的时机,我们看下这个示例就知道了
public static void main(String[] args) { |
结果是这样
876000 |
到乘第二个60的时候已经是负的了,因为已经超过了Integer的范围了
但是为啥用后面的示例转换成long类型还不行呢
这个就在于编译器是怎么做类型转换的
在第一个oneHundredYear跟24相乘的时候是认为两个Integer相乘,并且没有检查范围
只有在乘以显式申明的最后的1000的时候才会做转换
我们看下反编译
可以看到是先做int型的乘法,碰到有参数是long型时才会转类型
那么理论上其实我们只要在第二个60及之前申明long或者强转long就行了,这也是个很基础的问题,只是有时候写代码的时候直觉会以为加了个L就可以了,但实际是没那么简单
Exception in thread "main" com.alibaba.fastjson.JSONException: scan null error |
用一个简单的demo来复现下
public enum DemoEnum { |
先定义一个枚举类,然后有个demo类
public class FastJsonDemo implements Serializable { |
其中map的key是上面定义的枚举类,然后在main方法中做一下序列化和反序列化
public class demo { |
这样就会出现这个异常
Exception in thread "main" com.alibaba.fastjson.JSONException: scan null error |
这个异常有两个原因,第一当然是在map中出现了null作为key的数据,第二就是这个key是复杂对象
在反序列化以后就会出现这个异常,因为最初出现这个异常是因为我改了另一个字符串字段,并且会反序列化成json就让我判断出现了误差
这边做一个记录。
https://cr.console.aliyun.com/cn-beijing/instances/mirrors 上打开,阿里云用户都有各自的私有地址
https://xxxxxxxx.mirror.aliyuncs.com |
然后可以通过这个方式修改
sudo mkdir -p /etc/docker |
这样修改以后查看下日志
journalctl -xe --no-pager -u docker |
但还是拉不下来,后来发现还是拉不下来
应该也是之前被封的原因,
后面重要找到了一个
配置使用这个就可以了
{ |
或者拉取镜像的前缀加上这个地址docker pull dockerproxy.cn/yangchuansheng/derper:latest
也可以这么拉取,说实话docker镜像现在真的很必要,据说这次是因为传了某些敏感的AI语音
参考下面的图
还是像我这样的小白专属,消息队列用来干啥,很多都是标准答案,用来削峰填谷的,这个完全对,只是我想结合场景说给像我这样的小白同学听,想想一个电商的下单功能,除了 AT 两家之外应该大部分都是接入的支付,那么下单支付完成后一般都是等支付回调,告诉你支付完成了(也有可能是失败了,或者超时了咱们主动去查),然后这个回调里我们自己的业务代码干点啥,首先比如是把订单状态改掉了,然后会有各类的操作,比如把优惠券核销了,把其他金钱相关的也核销了,把购物车里对应的商品给删了,还有更次要的,比如发个客服消息,让用户确认下地址的,给用户加积分的等等等等,想象下如果这些都是回调里一股脑儿做掉了,那可能你的代码健壮性跟相关服务的稳定性还有性能要达到一个非常高的水平才能让业务不出现异常,并且万一流量打起来了,这些重要的不重要的操作都会阻塞着,所以需要用一个消息队列,在接到回调后只处理极少的几个核心操作,完了就把这个消息丢进消息队列里,让各个业务方去消费这个消息,把客服消息发一下,给用户加个积分等等,这样子主要的业务流程需要处理的事情就少了,速度也加快了,这个例子呢不能严格算是削峰填谷的例子,不过也算是消息队列的比较典型的使用场景了,要说真实的削峰填谷的话其实可以这么理解,假如短时间内有 1w 个请求进来,系统能支持的 QPS 才 1000,那么正常情况下服务就挂了,或者被限流了,为了让服务正常,那么可以把这些请求先放进消息队列里,我服务端以拉的模式按我的处理能力来消费,这样就没啥问题了
扯了这么多来聊聊 RocketMQ 长啥样

总共有四大部分:NameServer,Broker,Producer,Consumer。
NameServer是一个非常简单的Topic路由注册中心,其角色类似Dubbo中的zookeeper,支持Broker的动态注册与发现。主要包括两个功能:Broker管理,NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制,检查Broker是否还存活;路由信息管理,每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息,从而进行消息的投递和消费。NameServer通常也是集群的方式部署,各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息,所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了,Broker仍然可以向其它NameServer同步其路由信息,Producer,Consumer仍然可以动态感知Broker的路由的信息。
NameServer压力不会太大,正常情况主要负责维持心跳和提供Topic-Broker的关系数据。但有一点需要注意,Broker向Namesr发心跳时,会带上当前自己所负责的所有Topic信息,如果Topic个数太多,会导致一次心跳中,光Topic的数据就非常大,网络情况差的话,网络传输失败,心跳失败,导致Namesrv误认为Broker心跳失败。
Broker主要负责消息的存储、投递和查询以及服务高可用保证,为了实现这些功能,Broker包含了以下几个重要子模块。
1.负载均衡:Broker上存Topic信息,Topic由多个队列组成,队列会平均分散在多个Broker上,而Producer的发送机制保证消息尽量平均分布到所有队列中,最终效果就是所有消息都平均落在每个Broker上。
2.动态伸缩能力(非顺序消息):Broker的伸缩性体现在两个维度:Topic, Broker。
Topic维度:假如一个Topic的消息量特别大,但集群水位压力还是很低,就可以扩大该Topic的队列数,Topic的队列数跟发送、消费速度成正比。
Broker维度:如果集群水位很高了,需要扩容,直接加机器部署Broker就可以。Broker起来后想NameServer注册,Producer、Consumer通过NameServer发现新Broker,立即跟该Broker直连,收发消息。
3.高可用&高可靠
高可用:集群部署时一般都为主备,备机实时从主机同步消息,如果其中一个主机宕机,备机提供消费服务,但不提供写服务。
高可靠:所有发往broker的消息,有同步刷盘和异步刷盘机制;同步刷盘时,消息写入物理文件才会返回成功,异步刷盘时,只有机器宕机,才会产生消息丢失,broker挂掉可能会发生,但是机器宕机崩溃是很少发生的,除非突然断电
Producer与NameServer集群中的其中一个节点(随机选择)建立长连接,定期从NameServer获取Topic路由信息,并向提供Topic 服务的Master建立长连接,且定时向Master发送心跳。Producer完全无状态,可集群部署。
RocketMQ提供三种发送方式:
同步:在广泛的场景中使用可靠的同步传输,如重要的通知信息、短信通知、短信营销系统等。
异步:异步发送通常用于响应时间敏感的业务场景,发送出去即刻返回,利用回调做后续处理。
一次性:一次性发送用于需要中等可靠性的情况,如日志收集,发送出去即完成,不用等待发送结果,回调等等。
生产者发送时,会自动轮询当前所有可发送的broker,一条消息发送成功,下次换另外一个broker发送,以达到消息平均落到所有的broker上。
Consumer与NameServer集群中的其中一个节点(随机选择)建立长连接,定期从NameServer获取Topic路由信息,并向提供Topic服务的Master、Slave建立长连接,且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息,也可以从Slave订阅消息,消费者在向Master拉取消息时,Master服务器会根据拉取偏移量与最大偏移量的距离(判断是否读老消息,产生读I/O),以及从服务器是否可读等因素建议下一次是从Master还是Slave拉取。
先讨论消费者的消费模式,消费者有两种模式消费:集群消费,广播消费。
广播消费:每个消费者消费Topic下的所有队列。
集群消费:一个topic可以由同一个ID下所有消费者分担消费。
具体例子:假如TopicA有6个队列,某个消费者ID起了2个消费者实例,那么每个消费者负责消费3个队列。如果再增加一个消费者ID相同消费者实例,即当前共有3个消费者同时消费6个队列,那每个消费者负责2个队列的消费。
消费者端的负载均衡,就是集群消费模式下,同一个ID的所有消费者实例平均消费该Topic的所有队列。
消费者从用户角度来看有两种类型:
PullConsumer:主动从brokers处拉取消息。Consumer消费的一种类型,应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息,应用就会启动消费过程。
PushConsumer:Consumer消费的一种类型,该模式下Broker收到数据后会主动推送给消费端,该消费模式一般实时性较高。
Topic:主题,表示一类消息的集合,每个主题包含若干条消息,每条消息只能属于一个主题,是RocketMQ进行消息订阅的基本单位。Topic与生产者和消费者都是非常松散的关系,一个topic可以有0个或者1个或者多个生产者向其发送消息,换句话说,一个生产者可以同时向不同和topic发送消息。从消费者的解度来说,一个topic可能被0个或者一个或者多个消费组订阅,类似的,一个消费组可以订阅一个或者多个主题只要这个消费组的实例保持他们的订阅一致。
Message:消息消息系统所传输信息的物理载体,生产和消费数据的最小单位,每条消息必须属于一个主题。RocketMQ中每个消息拥有唯一的Message ID,且可以携带具有业务标识的Key。系统提供了通过Message ID和Key查询消息的功能。。
Message Queue:消息队列,一个主题被化分为一个或者多个子主题(sub-topics),“消息队列”.
Tag:标签,为消息设置的标志,用于同一主题下区分不同类型的消息。来自同一业务单元的消息,可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性,并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑,实现更好的扩展性。使用tag,同一业务模块不同目的的messages就可以用相同topic不同tag来标识。Tags有益于保持你的代码干净而条理清晰,同时促进使用RocketMQ提供的查询系统的效率。Topic:主题,是生产者发送的消息和消费者拉取的消息的归类。Topic与生产者和消费者都是非常松散的关系,一个topic可以有0个或者1个或者多个生产者向其发送消息,换句话说,一个生产者可以同时向不同和topic发送消息。从消费者的解度来说,一个topic可能被0个或者一个或者多个消费组订阅,类似的,一个消费组可以订阅一个或者多个主题只要这个消费组的实例保持他们的订阅一致。
Message Order:当使用DefaultMQPushConsumer时,你需要确定消费消息的方式:
Orderly:顺序地消费消息即表示消费的消息顺序同生产者发送的顺序一致。
Concurrently:并行消费。指定此方式消费,信息消费的最大并行数量仅受限于每个消费者客户端指定的线程池。
Consumer Group:消费组,同一类Consumer的集合,这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面,实现负载均衡和容错的目标变得非常容易。要注意的是,消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式:集群消费(Clustering)和广播消费(Broadcasting)。
Producer Group:生产者组,同一类Producer的集合,这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃,则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。
上面的这些我主要参考了 RocketMQ 的 GitHub 介绍和一些优秀网文的介绍,侵权请联系我删除。
]]>向量数据库在当今人工智能和机器学习领域扮演着越来越重要的角色。随着数据规模的不断扩大和应用场景的日益复杂,传统的数据库系统已经难以满足高维向量数据的快速检索需求。在这个背景下,近似最近邻(Approximate Nearest Neighbor, ANN)搜索问题成为了一个热点研究方向。
HNSW(Hierarchical Navigable Small World)算法是解决ANN问题的一种高效方法。它通过构建一个多层次的图结构,结合小世界网络的特性,实现了对高维向量数据的快速、精确检索。本文将深入浅出地介绍HNSW算法的核心思想、工作原理以及实际应用。
HNSW算法的核心思想可以概括为三个关键点:分层结构、小世界图和近似搜索。
HNSW采用了一种多层次的图结构。想象一下,如果我们要在一个大城市中找到一个特定的地址,我们通常会先看城市地图,然后逐步缩小范围到区、街道,最后定位到具体门牌号。HNSW的分层结构就类似于这种由粗到细的搜索过程。这个就是之前介绍跳表的目的,就是现在稀疏的结构里可以快速定位,然后再往下层进行搜索,提高了搜索效率
小世界网络是一种特殊的图结构,它具有较短的平均路径长度和较高的聚类系数。在HNSW中,每一层都是一个小世界图。这种结构使得在图中的任意两点之间都存在一条相对较短的路径,大大提高了搜索效率。
与传统的KNN(K-Nearest Neighbors)算法不同,HNSW通过牺牲一小部分精度来换取显著的速度提升。它不保证一定能找到真正的最近邻,但可以以极高的概率找到足够接近的点,而且搜索速度要快得多。
红色节点表示新插入的数据点。在这个例子中,新节点被插入到了层级0和层级1。
红色实线表示新建立的同层连接。新节点与其邻近节点建立了连接。
红色虚线表示新建立的跨层连接。新节点在不同层级之间建立了连接。
绿色虚线箭头表示插入过程的路径。这条路径展示了算法如何从顶层开始,逐层下降,最终确定新节点的插入位置。
其他颜色的节点和灰色的连接线表示原有的HNSW结构。
插入过程从顶层开始,沿着绿色虚线所示的路径向下搜索。
在每一层,算法都会寻找最近的邻居节点,并决定是否在该层插入新节点。
在本例中,新节点被插入到了层级0(基础层)和层级1。这是因为HNSW使用概率方法来决定节点应该出现在哪些层级。
插入后,新节点与其邻近节点建立连接(红色实线),以维持图的小世界特性。
同时,新节点也与其在不同层级的对应节点建立跨层连接(红色虚线),以确保层级之间的快速访问。
相比LSH(Locality-Sensitive Hashing)和Annoy等算法,HNSW在大多数场景下都能提供更好的查询性能和更高的准确率。然而,HNSW的内存消耗相对较高,这是它的一个潜在缺点。
HNSW可以用于快速检索相似用户或物品,提高推荐系统的响应速度和准确性。例如,在音乐推荐中,可以用HNSW快速找到与用户喜好相似的歌曲。
在大规模图像数据库中,HNSW可以实现快速的相似图像搜索。这在图像搜索引擎、视觉商品搜索等场景中非常有用。
HNSW可以用于词嵌入或句子嵌入的快速检索,支持语义相似度计算、文本分类等任务。
HNSW算法通过其独特的分层小世界图结构,在保证高准确率的同时实现了对高维向量数据的快速检索。它在推荐系统、图像检索、自然语言处理等多个领域都有广泛应用。
未来,向量数据库技术可能会朝着以下方向发展:
随着人工智能和大数据技术的不断发展,HNSW等高效的向量检索算法将在更广阔的应用场景中发挥重要作用。
]]>
|
默认的方法就跟普通的FunctionalInterface一样,就有一个apply方法,只是这里的特殊点有两个
这个BiFunction有三个泛型参数,T,U跟R,而这个R其实是具体方法的返回值
比如我们简单实现一个字符串拼接
BiFunction<String, String, String> biDemo = (s1, s2) -> s1 + s2; |
apply返回的就是参数R
这个方法是可以让结果再调用传入的方法,并返回结果
Function<String, Integer> funcDemo = String::length; |
定义了个函数接口,并且给了实现,就是字符串获取长度
然后传给biDemo,这样就可以输出拼接后的字符串长度
public <T1, T2, R1, R2> R2 combination(T1 t1, T2 t2, BiFunction<T1, T2, R1> biFunction, Function<R1, R2> function) { |
这样就把前面的两个方法串起来了
]]>https://github.com/wassupjay/n8n-free-templateshttps://n8n.io/workflows/preg_match(): Allocation of JIT memory failedpcre.jit 设置成 0HERD_PHP_74_INI_SCAN_DIR="/Users/dasun/Library/Application Support/Herd/config/php/74/"在日常使用云服务器的时候,如果要访问上面自建的 mysql,一般要不直接开对应的端口,然后需要对本地 ip 进行授权,但是这个方案会有比较多的限制,比如本地 ip 变了,比如是非固定出口 ip 的家用宽带,或者要在家里跟公司都要访问,如果对所有 ip 都授权的话会不安全,这个时候其实是用 ssh 端口转发是个比较安全方便的方式。
原来在这个之前其实对这块内容不太了解,后面是听朋友说的,vscode 的 Remote - SSH 扩展可以很方便的使用端口转发,在使用该扩展的时候,会在控制台位置里都出现一个”端口” tab
如图中所示,我就是将一个服务器上的 mysql 的 3306 端口转发到本地的 3307 端口,至于为什么不用 3306 是因为本地我也有个 mysql 已经使用了 3306 端口,这个方法是使用的 vscode 的这个扩展,
还有个方式是直接使用 ssh 命令
命令可以如此
ssh -CfNg -L 3307:127.0.0.1:3306 user1@199.199.199.199 |
简单介绍下这个命令-C 表示的是压缩数据包-f 表示后台执行命令-N 是表示不执行具体命令只用于端口转发-g 表示允许远程主机连接本地转发端口-L 则是具体端口转发的映射配置
上面的命令就是将远程主机的 127.0.0.1:3306 对应转发到本地 3307
而后面的用户则就是登录主机的用户名user1和ip地址199.199.199.199,当然这个配置也不是唯一的
还可以在ssh 的 config 配置中加对应的配置
Host host1 |
然后通过 ssh host1 连接服务器的时候就能顺带做端口转发
]]>public interface Processor { |
然后有两个实现
第一个实现是
public class FirstProcessor implements Processor{ |
第二个实现是
public class SecondProcessor implements Processor{ |
主要是为了示意,所以就把类名打了出来
我们通过一个http接口来调用下
|
这里通过autowired注解进行注入,此时我们可以运行起来看下执行顺序
看到控制台输出的确是有序的
this is FirstProcessor |
这个并不是spring这么智能知道我们的想法,只是刚好按字母顺序F在前
比如我们再加两个处理器
第三个
|
和第四个
|
然后我们请求下,就发现是
this is FirstProcessor |
没有按照我们想要的顺序执行
那么我们可以怎么做呢
通过spring的org.springframework.core.annotation.Order 注解
package org.springframework.core.annotation; |
通过value值来指定顺序,值越小,顺序越靠前
比如我们这
|
运行验证下的确是按照我们想要的顺序执行了
this is FirstProcessor |
org.springframework.core.Ordered 接口,需要实现 getOrder 方法
public interface Ordered { |
我们就在处理器里实现这个接口方法
public class FirstProcessor implements Processor, Ordered { |
运行下同样可以实现这个效果
this is FirstProcessor |
https://github.com/Sjj1024/PakePlus?tab=readme-ov-file
可以在 https://github.com/Sjj1024/PakePlus/releases 下载对应的版本
下载后打开长这样
点击➕号就能开始创建一个app
然后就是填入网页的地址,比如我这边想把我常用的一个crontab工具打包成一个app,
那就填入地址,以及相关的软件描述,还可以控制是否开启调试等
保存后就可以开始点击预览
这样一个简单的网页就打包成了一个mac上的app了,这里可能更多的场景是比如我就写了一个网页版的小工具,想打包成一个app来方便随时打开使用
比如本地的json工具等等,有些是自己定制的更趁手,还是非常不错的,记得之前这个开发者是可能做的命令行版的
这次是更彻底的界面化的比较傻瓜式的打包工具
方便很多不了解开发,命令行的同学进行使用
先聊聊这个事情,整体看下来我的一些理解,IPCC给中国的方案其实是个很大的陷阱,它里面有几个隐藏的点是容易被我们外行忽略的,第一点是基数,首先发达国家目前(指2010年采访或者IPCC方案时间)的人均碳排放量已经是远高于发展中国家的了,这也就导致了所谓的发达国家承诺减排80%是个非常有诚意的承诺其实就是忽悠;第二点是碳排放是个累计过程,从1900年开始到2050年,或者说到2010年,发达国家已经排的量是远超过发展中国家的,这是非常不公平的;第三点其实是通过前两点推导出来的,也就是即使发达国家这么有诚意地说减排80%,扒开这层虚伪的外衣,其实是给他们11亿人分走了48%的碳排放量,留给发展中国家55亿人口的只剩下了52%;第四点,人是否因为国家的发达与否而应受到不平等待遇,如果按国家维度,丁老说的,摩纳哥要跟中国分同样的排放量么,中国人还算不算人;第五点,这点算是我自己想的,也可能是柴静屁股决定脑袋想不到的点,她作为一个物质生活条件已经足够好了,那么对于那些生活在物质条件平均线以下的,他们是否能像城里人那样有空调地暖,洗澡有热水器浴霸,上下班能开车,这些其实都直接或者间接地导致了碳排放;他们有没有改善物质生活条件地权利呢,并且再说回来,其实丁老也给了我们觉得合理地方案,我们保证不管发达国家不管减排多少,我们都不会超过他们的80%,我觉得这是真正的诚意,而不是接着减排80%的噱头来忽悠人,也是像丁老这样的专家才能看破这个陷阱,碳排放权其实就是发展权,就是人权,中国人就不是人了么,或者说站在贫困线以下的人民是否有改善物质条件的权利,而不是说像柴静这样,只是管她自己,可能觉得小孩因为空气污染导致身体不好,所以做了穹顶之下这个纪录片,想去改善这个事情,空气污染不是说对的,只是每个国家都有这个过程,如果不发展,哪里有资源去让人活得好,活得好了是前提,然后再去各方面都改善。
对于这个问题其实更想说的是人的认知偏差,之前总觉得美帝是更自由民主,公平啥的,或者说觉得美帝啥都好,有种无脑愤青的感觉,外国的月亮比较圆,但是经历了像川普当选美国总统以来的各种魔幻操作,还有对于疫情的种种不可思议的美国民众的反应,其实更让人明白第一是外国的月亮没比较圆,第二是事情总是没那么简单粗暴非黑即白,美国不像原先设想地那么领先优秀,但是的确有很多方面是全球领先的,天朝也有体制所带来的优势,不可妄自菲薄,也不能忙不自大,还是要多学习知识,提升认知水平。
]]>Gpt-oss-120b 模型在核心推理基准测试中与 OpenAI o4-mini 模型几乎持平,同时能在单个 80GB GPU 上高效运行。Gpt-oss-20b 模型在常见基准测试中与 OpenAI o3‑mini 模型取得类似结果,且可在仅配备 16GB 内存的边缘设备上运行,使其成为设备端应用、本地推理或无需昂贵基础设施的快速迭代的理想选择。这两个模型在工具使用、少样本函数调用、CoT推理(如在 Tau-Bench 智能体评估套件中的结果所示)以及 HealthBench 测试中表现强劲(甚至超越了 OpenAI o1 和 GPT‑4o 等专有模型)。
gpt-oss 模型采用我们最先进的预训练和后训练技术进行训练,特别注重推理能力、效率以及在各种部署环境中的实际应用性。虽然我们已经公开发布了包括 Whisper 和 CLIP 在内的其他模型,但 gpt-oss 模型是我们自 GPT‑2[1]以来的首个开放大型语言模型。
每个模型都是一个 Transformer,它利用专家混合 (MoE[2]) 来减少处理输入所需的活跃参数数量。Gpt-oss-120b 每个令牌激活 51 亿个参数,而 gpt-oss-20b 激活 36 亿个参数。这两个模型的总参数数分别为 1,170 亿和 210 亿。这些模型采用交替的密集和局部带状稀疏注意力模式,与 GPT‑3 [3] 类似。为了提高推理和内存效率,这些模型还使用分组多查询注意力,分组大小为 8。我们使用旋转位置嵌入 (RoPE[4]) 进行位置编码,并原生支持长达 128k 的上下文长度。
| 模型 | 层数 | 总参数 | 每个令牌的活跃参数 | 总专家数 | 每个令牌的活跃专家数 | 上下文长度 |
|---|---|---|---|---|---|---|
| gpt-oss-120b | 36 | 117b | 5.1b | 128 | 4 | 128k |
| gpt-oss-20b | 24 | 21b | 3.6b | 32 | 4 | 128k |
比如我本地用ollama来运行了20b大小的,
ollama run gpt-oss:20b |
运行起来大概是占用了13g多点的内存,因为mac本身也有不少占用内存的以及我自己的一些后台运行的软件,所以比较捉襟见肘,有条件的上32g的mac mini可能比较富裕点
虽然现在ollama已经带了gui界面,但是发现运行的特别慢,直接通过命令行倒还是可以接受,比如我们问个Java相关的问题
>> 怎么成为Java架构师 |
首先是思维过程
Thinking... |
然后就是给出结果,体感是个位数token每秒的输出速度
以下就是生成的内容
架构师不是一次获得“技术标签”,而是一种综合的 设计思维 与 业务洞察 的能力。
下面给你一条完整、可量化的路线图,帮助你从“有经验的 Java 开发者”成长为 架构师。
小贴士:如果你手头已有 3–5 年的项目经验,就可以直接对应后面的“实战经验”板块。如果你刚起步,建议先走“技术打底”阶段,然后再投身实战。
| 目标 | 必备技术 / 书籍 / 练手 | 练习建议 |
|---|---|---|
| Java 基础 | Java SE 8+(lambda, stream, JPA 等) | 先练手 OOP、设计模式、并发,做 Leetcode、练下 JDK 内部实现(如 ArrayList、HashMap) |
| 框架 | Spring Framework(MVC、AOP)、Spring Boot、Spring Cloud、Spring Data JPA | 搭建多层 CRUD + MVC + Security + Redis + MySQL 的完整项目 |
| ORM | Hibernate / JPA | 写复杂的查询,掌握 Fetch 策略、缓存、懒加载 |
| 数据库 | 关系型(MySQL/PostgreSQL) + NoSQL(MongoDB / Redis) | 学习分库分表、事务、读写分离 |
| 安全 | OAuth2 / JWT / Spring Security | 单独做一套认证系统 |
| 单元测试 | JUnit、Mockito | 代码覆盖率≥90% |
| CI/CD | Git, Maven/Gradle, Docker, Jenkins/GitHub Actions | 自动化构建、单元/集成测试、镜像推送 |
| 监控 | Micrometer + Prometheus + Grafana / ELK | 记录度量、日志、告警 |
| 微服务 | Spring Cloud(Nacos/Spring Cloud Config + Eureka/Consul + Zuul/Gateway + Hystrix) | 搭建 3‑5 个小服务,练习服务间调用与降级 |
| 消息中间件 | Kafka / RabbitMQ | 读写队列,练习发布/订阅,事务与回滚 |
| 分布式事务 | Saga、TCC、XA | 通过 Spring Transaction、Atomikos 练习 |
学习资源(中文 / 英文)
| 主题 | 书籍 | 课程 | 文章 / 官网 |
|---|---|---|---|
| Java | 《Java 编程思想》, 《深入理解 Java 虚拟机》 | 《Java 8+ 入门与进阶》(慕课, 极客时间) | Oracle JDK 官网, 《Effective Java》解读 |
| Spring | 《Spring 实战 5》, 《Spring Cloud 实战》 | Spring 官方培训,Bilibili / 慕课 | Spring 官网 & Spring Cloud 官网 |
| 微服务 | 《微服务设计》, 《Domain-Driven Design》 | 《Spring Cloud 全栈》(极客时间) | 微服务架构图 (Zhou’s blog, DZone) |
| 大数据 / Kafka | 《Kafka 权威指南》 | 《Kafka 入门 & 进阶》 | Apache Kafka 官网 |
| 系统设计 | 《系统架构设计》, 《分布式系统设计之道》 | 《系统设计基础》课程 | 阿里云、腾讯云白皮书 |
练手项目:做一个 电商平台 或 社交系统,分拆为多个服务:用户服务、商品服务、订单服务、支付服务、物流服务等。通过实现 **统一鉴权、限流、熔断、日志聚合
**,让自己彻底体验架构层面的痛点。
| 类别 | 经典模式 | 示例 |
|---|---|---|
| 业务层 | 领域模型 (Domain Model), 领域事件 (Domain Event) | 商品模块使用领域事件实现库存同步 |
| 持久层 | DAO, Repository, Unit of Work | JPA Repository + UnitOfWork |
| 基础设施 | 适配器 (Adapter), 代理 (Proxy), 桥接 (Bridge) | 用 Feign+Ribbon 代理调用第三方支付 |
| 核心架构 | 微服务, 事件驱动, Command Query Responsibility Segregation (CQRS), Event Sourcing, Saga | 微服务 + Kafka |
| 运行时 | 延迟策略 (Retry), 熔断 (Circuit Breaker), 限流 (Limiter), 负载均衡 (LoadBalancer) | Hystrix + Ribbon + Sentinel |
书单:
- 《Design Patterns》 经典翻译版
- 《架构师的选型与设计》
- 《系统架构师的自我修养》
- 《大规模分布式系统架构》(阿里巴巴架构师经验分享)
| 领域 | 关键能力 | 学习路径 |
|---|---|---|
| 产品思维 | 理解业务目标、价值主张 | 与 PO、BA 讨论,用业务故事拆解 |
| 沟通 | 需求梳理、技术方案说明 | 每周至少 1 次技术分享或午餐会 |
| 领导 | 组内技术指导、冲刺规划 | 作为 scrum master 或技术负责人 |
| 安全 & 合规 | 数据加密、GDPR/HIPAA | 学习安全框架、法规手册 |
| 成本管理 | 云成本、容量规划 | 通过 Cloud Cost Estimator 评估 |
练习:把上面 4 大主题写成 PPT,给同事做一个半小时的技术分享,随后收集反思与改进。
| 阶段 | 目标 | 关键步骤 |
|---|---|---|
| 技术负责人 | 完成 3–5 个核心模块的技术方案。 | 按模块负责并交付。 |
| 架构师 | 对整个平台制定 技术愿景、技术选型、非功能性指标。 | 1)制定技术路线图;2)做安全、数据治理、成本管控。 |
| 架构顾问 | 对多家企业/业务线提供架构咨询。 | 参与技术评审、代码走查、培训。 |
| 高层 CxO(CTO/VP) | 负责技术战略、团队治理。 | 培养团队、构建技术生态。 |
核心任务
- 选型:在技术评估、成本评估、稳定性、社区支持等要素上做出决策。
- 方案落地:把抽象设计写成 可执行的计划。
- 治理:制定 编码规范、CI/CD 标准、安全策略、成本追踪。
- 治理工具:使用 ArgoRollouts、Helm、OPA(Open Policy Agent)来实现自动化治理。
| 月份 | 阶段 | 关键任务 |
|---|---|---|
| 1–6 | Java 基础 & Spring Boot | 1 个 CRUD 项目 |
| 7–12 | 中间件 & 微服务 | 3 个微服务 + 统一鉴权 |
| 13–18 | 系统设计 & DDD | 业务拆解、领域模型 |
| 19–24 | 分布式 & 缓存 | Kafka、Redis、分布式事务 |
| 25–36 | 云原生 & 运维 | Kubernetes + Prometheus + Zipkin |
| 37–48 | 设计模式 & 框架 | 事件驱动、Saga、CQRS |
| 49–60 | 软技能 & 领导 | 组内技术分享、技术评审 |
| 60+ | 架构师 | 制定技术愿景、治理 |
关键点:每个阶段都要有交付。写好技术文档、代码库、可复现的 demo,让别人能够看到你“解决了什么”而不是仅仅“看懂你说了些什么”。
| 验证方式 | 说明 |
|---|---|
| 技术博客 / 公开课 | 发布 8+ 篇系统设计技术文章,完成 1 次公开技术分享。 |
| GitHub 项目 | 至少 3 个真实业务项目或开源项目,PR 贡献。 |
| 项目验收记录 | 给同事或客户交付至少 2 次业务改造。 |
| 面试评估 | Top 技术平台(猎聘、BOSS 直聘)上,面试 “架构师” 级别。 |
| 认证 | Oracle Certified Professional、AWS Certified Solutions Architect – Professional、阿里云架构师认证 等。 |
面试题准备
- 业务场景 → 需求分析 → 系统架构 → 数据模型 → 性能方案 → 监控与运维 → 失败模式与可恢复性
- 经典面试题:
- 给定
100 个并发用户同时下单,怎么防止库存穿透?- 如何实现微服务之间的 幂等调用?
- 解释“CAP定理”并给出符合业务的解决方案。
结语
成为 Java 架构师是一段 从 “熟练编码” → “系统设计” → “业务与技术双栖” 的成长旅程。只要你把每一步拆解成可执行的目标,系统练习并且用落地项目检验自己的能力,就
能稳扎稳打地迈向架构师角色。祝你早日成为团队里的架构引路人!
如果你想进一步细化任何一板块(如某个具体的技术选型、微服务拆分方案,或是面试技巧),随时告诉我!祝你编码愉快 🚀✌️
]]>内容正确性仅供参考
只是输出的质量体感可能赶得上最初版的chatgpt了,按这种效果本地用来做一些辅助工作的能力感觉是够用了。根据官方的测评20b的模型也是超过了o3-mini,主要是目前的内存占用还比较吃力对我来说,如果是32g内存的话应该就比较舒服了,也期待会有更小的且效果不输于gpt-oss:20b的模型,本地的模型使用就会越来越普遍且好用
/usr/libexec/java_home 切换下JAVA_HOMEexport JAVA_HOME=$(/usr/libexec/java_home -v 21) |
首先是试一下线程版本
long start = System.currentTimeMillis(); |

耗时5897ms
long start = System.currentTimeMillis(); |

耗时154ms
相对来说还是能快很多的
而核心的虚拟线程实现主要来自于调度
static Thread newVirtualThread(Executor scheduler, |
在创建虚拟线程过程中,我们需要去处理调度器,初始时调度器为空
VirtualThread(Executor scheduler, String name, int characteristics, Runnable task) { |
而这个默认调度器就是
private static final ForkJoinPool DEFAULT_SCHEDULER = createDefaultScheduler(); |
对应创建的就是个ForkJoinPool
private static ForkJoinPool createDefaultScheduler() { |
可以看到参数都是通过系统参数获取,或者用系统的cpu数量来决定并行度,主体的逻辑就是既然系统线程开销大,那我就在系统线程内部模拟一个更小颗粒度的,在线程内部进行调度的模型,以此来减少系统切换开销,只不过细节还有很多需要研究,有兴趣的可以留言探讨
]]>npm install -g @google/gemini-cli |
然后在环境变量里设置gemini key
export GEMINI_API_KEY="xxxxxxxx" |
接着运行gemini就可以啦
这里我是刚好有个需求,因为娃最近有点不太爱喝奶,经常剩下,想要记录统计下,看看每天的总的奶量
那我就建了个空的目录,并在这个目录下运行了 gemini ,然后输入了我的需求,
原始的诉求是这样我想要写个网页版小程序,可以按时间记录宝宝每次的奶量,包括泡了多少,剩了多少,能按天统计每天的奶量,以及查看趋势
然后gemini就开始运行
✦ 好的,这个需求很明确,我们可以创建一个名为“奶量备忘” (Milk Memo) 的网页应用来实现它。 |
然后我输入了同意他就开始帮我实现了
它会请求我的同意来运行比如npm命令,安装依赖等等
然后就自己运行了npm start 来演示运行这个应用
不算非常有设计感,但是基本的功能是已经实现了
接着我又让它帮我增加了时间选项,以及趋势图查看功能,
接着它就又生成了一版
✦ 功能已经更新完毕。 |

感觉完成了所需的95%的功能,除了在设计上还能再美观些,以及增加一些服务端存储数据的功能,基本是个比较完善的,我自己都完全没介入,的确ai的发展真的一日千里,另外我还是比较看好谷歌的,没有什么大新闻,就一直努力追赶,现在基本已经是第一梯队了,很好很强大
lmstudio-community/DeepSeek-R1-Distill-Qwen-7B-GGUF/DeepSeek-R1-Distill-Qwen-7B-Q4_K_M.gguf 这个模型,Qwen2.5-Math-7B 通过监督微调(SFT)从 DeepSeek-R1 生成的数据集上训练得到的。 所以基础模型来说它是有目的性的,主要为数学方向做的训练,在此基础上会学习到 deepseek-r1 的推理能力D:\Program Files\LM Studio 我的是自己修改过的,常规的方式可以在桌面 LM Studio 图标上右键,然后点击 “打开文件所在的位置” 就可以找到LM Studio 的安装目录了,然后继续打开安装目录中的 resources 文件夹,再打开其中的 app 目录,就可以看到一个 .webpack 文件夹,建议用 vscode 或者sublime 打开目录,然后全局搜索 huggingface.co 替换成镜像地址 hf-mirror.com,然后重新打开 LM Studio 就可以搜索到上面提到的模型了,可能是由于这个镜像站没那么充足的资源,一般是白天的下载速度会快一点,晚上一般速度不太行,有条件的可以上全局代理,不过幸好 LM Studio 是支持断点续传的,只是它的下载很容易超时后自动异常,并不会自动重试,,这是个比较头疼的地方。deepseek-r1 ,这类暂时不考虑在内,如果只是一些简单的使用场景,可以把上下文的大小调小一些,这样可以加快生成速度9.11跟9.08 哪个大towhee 跟 milvus 实现了图片的向量化,那么顺势我们就能在这个基础上实现以图搜图from towhee import AutoPipes, AutoConfig, ops |
然后我们找一张神仙姐姐的其他图片,先把它 embedding 后在 milvus 里进行向量检索
image_embedding_pipe = AutoPipes.pipeline('image-embedding') |
我们检索出来5个结果,
可以通过distance找到距离最近的这个是id=451291280409722600
可以发现也是神仙姐姐的,只是作为参考
to_search 目标图片是
搜索的最短距离就是id对应的图片
这张图片就是神仙姐姐
2025/05/11 21:16:04 NOTICE: Failed to copy: failed to prepare upload: operation error S3: CreateBucket, https response error StatusCode: 403, RequestID: , HostID: , api error AccessDenied: Access Denied |
这个403的错误,结果谷歌搜索了下
可以通过这个选项进行屏蔽
--s3-no-check-bucket |
这样我就能用
./rclone --s3-no-check-bucket copy ~/Downloads/r2/test_for_rclone.png r2_new:blog |
来上传了,只是这里相比uPic麻烦了两步,第一截图后需要对文件进行命名,不然就是qq截图或者微信截图的文件名,
第二上传后需要自己拼图片的链接,当然希望是能够使用uPic的,但目前的问题是uPic似乎对于s3协议的支持不那么好
噢,对了,我用的是直接基于开源代码的自己打包版本,个人感觉还有点不太习惯从免费用成付费软件,主要是它是开源的
打算空了再折腾打包试试,或者自己调试下,实在不行就付费了
NullPointerException,而往往这种异常我们在查看日志的时候都是根据打印出来的异常堆栈找到对应的代码以确定问题,但是有一种情况会出现一个比较奇怪的情况,虽然我们在日志中打印了异常
log.error("something error", e); |
这样是可以打印出来日志,譬如 slf4j 就可以把异常作为最后一个参数传入
void error(String var1, Throwable var2); |
有的时候如果不小心把异常通过占位符传入就可能出现异常被吞的情况,不过这点不是这次的重点
即使我们正常作为最后一个参数传入了,也会出现只打印出来
something error, java.lang.NullPointerException: null |
这样就导致了如果我们这个日志所代表的异常包含的代码范围比较大的话,就不确定具体是哪一行出现的异常,除非对这些代码逻辑非常清楚,这个是为什么呢,其实这也是 jvm 的一种优化机制,像我们目前主要还在用的 jdk8中使用的 jvm 虚拟机 hotspot 的一个热点异常机制,对于这样一直出现的相同异常,就认为是热点异常,后面只会打印异常名,不再打印异常堆栈,这样对于 io 性能能够提供一定的优化保证,这个可以通过 jvm 启动参数-XX:-OmitStackTraceInFastThrow 来关闭优化,这个问题其实在一开始造成了一定困扰,找不准具体是哪一行代码,不过在知道这个之后简单的重启也能暂时解决问题。
HISTSIZE=1000 |
比如设置1000个命令大小,只是在Termux里不是这个原因,而是在于shell去保存历史的时机,安卓手机在退出应用或者切换应用程序都没法记录这个执行历史,而是需要在Termux中手动地用exit命令退出,才会记录下history历史,
当然也有人在Termux的issue上提到了,能不能捕捉安卓的事件来执行这个exit,否则这个exit有点难记得,相对来说也不方便了很多,容易遗忘,只是这个issue也被关掉了,看看后面会不会优化吧
|
而在这个demoService中它的实现是这样
public String queryName(String no) { |
假如现在Controller这的这个方法有点问题,那么我想确认下是不是demoService这个方法的实现有问题,或者说确定下它的返回值是否符合预期
那么我们就可以在应用启动后,运行arthas,找到这个应用的进程,进行挂载
然后执行
vmtool --action getInstances --className com.nicksxs.spbdemo.service.DemoServiceImpl --express 'instances[0].queryName("1")' |
先介绍下这个vmtool命令
主要来说 vmtool 可以利用JVMTI接口,实现查询内存对象,强制 GC 等功能。
例如官方示例里的,我想把内存里的string对象捞一些出来看看存的是啥
vmtool --action getInstances --className java.lang.String --limit 10 |
就可以这样,首先这个action就是指定要做的操作,支持的action 还包括
forceGc |
等,那么对于 getInstances 就是从内存里捞出这个类的对象,然后是后面一部分--express 就是执行表达式,这里的表达式,instances[0].queryName("1") 其中 instances 就是前面从内存中获取的对象数组,因为这些是对象的非静态方法,那就需要从其中取一个来执行我们的方法
另外假如我们的场景里需要对比如返回结果做个json序列化
我们可以这样
vmtool --action getInstances --className com.nicksxs.spbdemo.service.DemoServiceImpl --express '@com.alibaba.fastjson.JSON@toJSONString(instances[0].queryName("1"))' |
这里为什么类开头跟方法开头要用 @, 是因为对于类和静态方法的调用规则是这样,还有如果代码比较多,有可能默认的类加载器中没有加载这个JSON类,那么就需要在参数中加上指定的classloader,
可以用sc命令来查找我们的目标类的类加载器,一般来说如果目标类是我们核心业务的,大概率也会有JSON这个类
sc -d com.nicksxs.spbdemo.service.DemoServiceImpl |
然后在上面命令中加上sc结果中的 classLoaderHash 的值,
vmtool --action getInstances -c 18b4aac2 --className com.nicksxs.spbdemo.service.DemoServiceImpl --express '@com.alibaba.fastjson.JSON@toJSONString(instances[0].queryName("1"))' |
这样就能正常执行了
]]>0xc00000e9 错误码,现在想着是不是这个固态硬盘有点问题或者还是内存问题,只能后续再看了,拆机的时候也找不到视频,机器实在是太老了,后面再试试看。
]]>最近这次经历也是有火绒的一定责任,在我尝试推出 U盘的时候提示了我被另一个大流氓软件,XlibabaProtect.exe 占用了,这个流氓软件真的是充分展示了某里的技术实力,试过 N 多种办法都关不掉也删不掉,尝试了很多种办法也没办法删除,但是后面换了种思路,一般这种情况肯定是有进程在占用 U盘里的内容,最新版本的 Powertoys 会在文件的右键菜单里添加一个叫 File Locksmith 的功能,可以用于检查正在使用哪些文件以及由哪些进程使用,但是可能是我的使用姿势不对,没有仔细看文档,它里面有个”以管理员身份重启”,可能会有用。
这算是第一种方式,
第二种方式是 Windows 任务管理器中性能 tab 下的”打开资源监视器”,
,假如我的 U 盘的盘符是F:
就可以搜索到占用这个盘符下文件的进程,这里千万小心‼️‼️,不可轻易杀掉这些进程,有些系统进程如果轻易杀掉会导致蓝屏等问题,不可轻易尝试,除非能确认这些进程的作用。
对于前两种方式对我来说都无效,
所以尝试了第三种,
就是磁盘脱机的方式,在”计算机”右键管理,点击”磁盘管理”,可以找到 U 盘盘符右键,点击”脱机”,然后再”推出”,这个对我来说也不行
这种是唯一对我有效的,在开始菜单搜索”event”,可以搜到”事件查看器”,
,这个可以看到当前最近 Windows 发生的事件,打开这个后就点击U盘推出,因为推不出来也是一种错误事件,点击下刷新就能在这看到具体是因为什么推出不了,具体的进程信息
最后发现是英特尔的驱动管理程序的一个进程,关掉就退出了,虽然前面说的某里的进程是流氓,但这边是真的冤枉它了
range revert来进行 git revert, 用法就是
git revert OLDER_COMMIT^..NEWER_COMMIT |
这样就可以解决上面的问题了,但是还有个问题是这样会根据前面的 commit 数量提交对应数量个 revert commit 会显得比较乱,如果要比较干净的 commit 历史,
可以看下 git revert 命令说明
然后就可以用 -n 参数,表示不自动提交
git revert -n OLDER_COMMIT^..NEWER_COMMIT |
zsh: no matches found: root@100.100.100.100://root/prefix* |
这里就比较奇怪了,这个前缀的文件肯定是有的,这里其实是由于 zsh 会对 * 进行展开,这个可以在例如 ls 命令在使用中就可以发现 zsh 有这个特性
需要使用双引号或单引号将路径包起来或者在*之前加反斜杠\来阻止对*展开和转义
scp root@100.100.100.100://root/prefix* . |
通过使用双引号"进行转义
scp root@100.100.100.100:"//root/prefix*" . |
或者可以将 shell 从 zsh 切换成 bash
]]>Proxy SwitchyOmega 2 平时会用来做代理切换,原本的仓库已经没人维护了,并且chrome扩展商店也没有更新,~/Library/Application Support/Google/Chrome/Default/ExtensionsC:\Users\<用户名>\AppData\Local\Google\Chrome\User Data\Default\Extensionsmanifest.json 文件,把版本改成3chrome-extension://padekgcemlokbadohgkifijomclgjgif/options.htmlchrome://flags/#allow-legacy-mv2-extensionswget https://raw.githubusercontent.com/milvus-io/milvus/master/scripts/standalone_embed.sh |
启动过程中需要注意一些问题,这也是有点想吐槽的,这个官方的启动脚本竟然都不是稳定成功的,最开始就是失败的,后面重新删除拉下来的镜像再启动就好了
并且官方提供的demo python版本的示例也是有问题的
因为主要是java的缘故,就用了java的sdk来尝试
只是我们可以先运行一个ui工具
docker run -p 8000:3000 -e MILVUS_URL={milvus server IP}:19530 zilliz/attu:v2.4 |

这里就能看到运行情况
然后我们运行个简单的代码
package MilvusDemo; |
我们用同样的向量进行搜索
[SearchResp.SearchResult(entity={my_id=0, $meta={"color":"pink_8682"}, my_vector=[0.35803765, -0.6023496, 0.18414013, -0.26286206, 0.90294385]}, score=1.4093276, id=0)] |
得出的score就是很高的,只是做了下尝试,官方的示例代码是少得可怜,也不全,很难想象是目前比较热门的向量数据库
]]>HNSW 是个比较重要且核心的概念,直接学习(面向小白)可能有一定的门槛,所以我们先通过常见算法的跳表来做个引入1 --> 2 --> 3 --> 4 --> 5 --> 6 --> 7 --> 8 --> 9 |
这样的链表,我要查找8个元素是否存在,那我需要查找八次才能找到
如果我把结构改成
1 --------------> 4 --------------> 7 ---------> null |
变成这样的结构,我现在第一层找最后一个比8小的元素,就是7,然后再到下一层查找,这样我的查找路径就是 1 --> 4 --> 7 --> 8 速度加快了一倍
直观来说这样是能够提升很多查询效率,但是具体怎么实现我们也来看一下
首先定义个简单的Node
public class Node { |
接下去是SkipList的主体结构
public class SkipList { |
包含最大层数,当前层数,头结点,跟随机值
生成随机层数参考了redis的zset实现方法
private int generateRandomLevel() { |
接下去先看下
public void insert(int value) { |
看下图片演示,类似于链表的插入,但是需要处理每一层的前后链接
public Node search(int value) { |
也可以看下图里的演示,按红色的线寻找元素
public void delete(int value) { |
删除操作就类似于插入操作。了解了跳表原理以后其实HNSW就是个在空间层面的跳表
SELECT FOR UPDATE 是 MySQL 中一种特殊的查询语句,它在执行查询的同时对选中的行加上排他锁(Exclusive Lock),确保在当前事务结束之前,其他事务无法修改这些数据。这种机制主要用于解决并发环境下的数据一致性问题。
SELECT column1, column2, ... FROM table_name WHERE condition FOR UPDATE; |
当执行 SELECT FOR UPDATE 时,MySQL 会:
电商系统中最常见的应用场景:
-- 开始事务 |
这里也可以直接使用start; 开启事务,
确保序列号的唯一性:
START TRANSACTION; |
银行转账等涉及账户余额的操作:
START TRANSACTION; |
-- 情况1:使用主键或唯一索引(精确锁定) |
-- 事务 A |
这样就会造成死锁等待,注意一点死锁不一定是两个事务相互等待,也可以是循环等待,要达到的是竞态等待
-- 事务 A |
这样也会造成死锁,所以不要把死锁就单纯理解为两个线程互相等待
-- 优化前:全表扫描,锁定大量行 |
-- 避免:锁定所有字段 |
-- 不推荐:事务过长 |
-- 错误:不在事务中,锁立即释放 |
-- 检查自动提交状态 |
-- 设置锁等待超时时间(秒) |
-- 使用版本号实现乐观锁 |
-- 直接使用原子性的 UPDATE |
SELECT FOR UPDATE 是 MySQL 中解决并发问题的重要工具,但使用时需要注意:
正确使用 SELECT FOR UPDATE 可以有效保证数据一致性,但也要权衡其对系统性能的影响,在实际应用中需要根据具体业务场景做出合理的选择。
]]>ip a来查看,可以看到这个 ip 是172网段的,而在 wsl 1 中可以看到 ip 就是 win 的 ip,sudo apt update |
另外如果需要提高安全性,可以wsl 中配置 hosts.allow
sshd:192.168.xx. |
先定一个子网段,然后对于ssh的配置,可以做以下修改
Port 22 |
在进行重启
sudo service ssh --full-restart |
配置以后发现上面的问题,没法远程登录,因为 wsl 2 是基于 hyper-v 虚拟机实现的,并且 ip 使用的是一个虚拟出来的子网 ip,所以需要在 Windows 这一层配置端口的转发,可以通过命令netsh interface portproxy show v4tov4看到
截图是我已经添加好了的,先把原来的删除,再进行添加
netsh interface portproxy delete v4tov4 listenaddress=0.0.0.0 listenport=22 |
也可以全量删除
netsh int portproxy reset all |
但是这样也不能直接访问了,还需要开启防火墙
netsh advfirewall firewall add rule name="WSL SSH" dir=in action=allow protocol=TCP localport=22 |
前面这两周周末也都去老丈人家帮忙了,上上周周六先是去了那个在装修的旧房子那,把三楼收拾了下,因为要搬进来住,来不及等二楼装修好,就要把三楼里的东西都整理干净,这个活感觉是比较 easy,原来是就准备把三楼当放东西仓储的地方了,我们乡下大部分三层楼都是这么用的,这次也是没办法,之前搬进来的木头什么的都搬出去,主要是这上面灰尘太多,后面清理鼻孔的时候都是黑色的了,把东西都搬出去以后主要是地还是很脏,就扫了地拖了地,因为是水泥地,灰尘又太多了,拖起来都是会灰尘扬起来,整个脱完了的确干净很多,然而这会就出了个大乌龙,我们清理的是三楼的西边一间,结果老丈人上来说要住东边那间的🤦♂️,不过其实西边的也得清理,因为还是要放被子什么的,不算是白费功夫,接着清理东边那间,之前这个房子做过群租房,里面有个高低铺的床,当时觉得可以用在放被子什么的就没扔,只是拆掉了放旁边,我们就把它擦干净了又装好,发现螺丝🔩少了几个,亘古不变的真理,拆了以后装要不就多几个要不就少几个,不是很牢靠,不过用来放放被子省得放地上总还是可以的,对了前面还做了个事情就是铺地毯,其实也不是地毯,就是类似于墙布雨篷布那种,别人不用了送给我们的,三楼水泥地也不会铺瓷砖地板了就放一下,干净好看点,不过大小不合适要裁一下,那把剪刀是真的太难用了,我手都要抽筋了,它就是刀口只有一小个点是能剪下来的,其他都是钝的,后来还是用刀片直接裁,铺好以后,真的感觉也不太一样了,焕然一新的感觉
差不多中午了就去吃饭了,之前两次是去了一家小饭店,还是还比较干净,但是店里菜不好吃,还死贵,这次去了一家小快餐店,口味好,便宜,味道是真的不错,带鱼跟黄鱼都好吃,一点都不腥,我对这类比较腥的鱼真的是很挑剔的,基本上除了家里做的很少吃外面的,那天抱着试试的态度吃了下,真的还不错,后来丈母娘说好像这家老板是给别人结婚喜事酒席当厨师的,怪不得做的好吃,其实本来是有一点小抗拒,怕不干净什么的,后来发现菜很好吃,而且可能是老丈人跟干活的师傅去吃的比较多,老板很客气,我们吃完饭,还给我们买了葡萄吃,不过这家店有一个槽点,就是饭比较不好吃,有时候会夹生,不过后面聊起来其实是这种小菜馆饭点的通病,烧的太早太多容易多出来浪费,烧的迟了不够吃,而且大的电饭锅比较不容易烧好。
下午前面还是在处理三楼的,窗户上各种钉子,实在是太多了,我后面在走廊上排了一排🤦♂️,有些是直接断了,有些是就撬了出来,感觉我在杭州租房也没有这样子各种钉钉子,挂下衣服什么的也不用这么多吧,比较不能理解,搞得到处都是钉子。那天我爸也去帮忙了,主要是在卫生间里做白缝,其实也是个技术活,印象中好像我小时候自己家里也做过这个事情,但是比较模糊了,后面我们三楼搞完了就去帮我爸了,前面是我老婆二爹在那先刷上白缝,这里叫白缝,有些考究的也叫美缝,就是瓷砖铺完之后的缝,如果不去弄的话,里面水泥的颜色就露出来了,而且容易渗水,所以就要用白水泥加胶水搅拌之后糊在缝上,但是也不是直接糊,先要把缝抠一抠,因为铺瓷砖的还不会仔细到每个缝里的水泥都是一样满,而且也需要一些空间糊上去,不然就太表面的一层很容易被水直接冲掉了,然后这次其实也不是用的白水泥,而是直接现成买来就已经配好的用来填缝的,兑水搅拌均匀就好了,后面就主要是我跟我爸在搞,那个时候真的觉得我实在是太胖了,蹲下去真的没一会就受不了了,膝盖什么的太难受了,后面我跪着刷,然后膝盖又疼,也是比较不容易,不过我爸动作很快,我中间跪累了休息一会,我爸就能搞一大片,后面其实我也没做多少(谦虚一下),总体来讲这次不是很累,就是蹲着跪着腿有点受不了,是应该好好减肥了。
第四周去的时候让我们去了现在在住的房子里,去三楼整理东西了,蛮多的东西需要收拾整理,有些需要丢一下,以前往往是把不太要用的东西就放三楼了,但是后面就不会再去收拾整理,LD 跟丈母娘负责收拾,我不太知道哪些还要的,哪些不要了,而且本来也不擅长这种收拾🤦♂️,然后就变成她们收拾出来废纸箱,我负责拆掉,压平,这时候终于觉得体重还算是有点作用,总体来说这个事情我其实也不擅长,不擅长的主要是捆起来,可能我总是小题大做,因为纸箱大小不一,如果不做一下分类,然后把大的折小一些的话,直接绑起来,容易拎起来就散掉了,而且一些鞋盒子这种小件的纸盒会比较薄,冰箱这种大件的比较厚,厚的比较不容易变形,需要大力踩踏,而且扎的时候需要用体重压住捆实了之后那样子才是真的捆实的,不然待会又是松松垮垮容易滑出来散架,因为压住了捆好后,下来了之后箱子就会弹开了把绳子崩紧实,感觉又是掌握到生活小技巧了😃,我这里其实比较单调无聊,然后 LD 那可以说非常厉害了,一共理出来 11 把旧电扇,还有好多没用过全新的不锈钢脸盆大大小小的,感觉比店里在卖的还多,还有是有比较多小时候的东西,特别多小时候的衣服,其实这种对我来说最难了,可能需要读一下断舍离,蛮多东西都舍不得扔,但是其实是没啥用了,然后还占地方,这天应该算是比较轻松的一天了,上午主要是把收拾出来要的和不要的搬下楼,然后下午要去把纸板给卖掉。中午还是去小快餐店吃的,在住的家里理东西还有个好处就是中午吃完饭可以小憩一下,因为我个人是非常依赖午休的,不然下午完全没精神,而且心态也会比较烦躁,一方面是客观的的确比较疲惫,另一方面应该主观心理作用也有点影响,就像上班的时候也是觉得不午睡就会很难受,心理作用也有一点,不过总之能睡还是睡一会,真的没办法就心态好点,吃完午饭之后我们就推着小平板车去收废品的地方卖掉了上午我收拾捆起来的纸板,好像卖了一百多,都是直接过地磅了,不用一捆一捆地称,不过有个小插曲,那里另外一个大爷在倒他的三轮车的时候撞了我一下,还好车速慢,屁股上肉垫后,接下来就比较麻烦了,是LD 她们两姐妹从小到大的书,也要去卖掉,小平板车就载不下了,而且着实也不太好推,轮子不太平,导致推着很累,书有好多箱,本来是想去亲戚家借电动三轮车,因为不会开摩托的那种,摩托的那种 LD 邻居家就有,可是到了那发现那个也是很大,而且刹车是用脚踩的那种,俺爹不太放心,就说第二天周日他有空会帮忙去载了卖掉的,然后比较搞笑的来了,丈母娘看错了时间,以为已经快五点了,就让我们顺便在车里带点东西去在修的房子,放到那边三楼去,到了那还跟老丈人说已经这么迟了要赶紧去菜场买菜了,结果我们回来以后才发现看错了一个小时🤦♂️。
前面可以没提,前三周去的我们一般就周六去一天,然后周日因为要早点回杭州,而且可能想让我们周日能休息下,但是这周就因为周日的时候我爸要去帮忙载书,然后 LD 姐姐也会过来收拾东西,我们周日就又去整理收拾了,周日由于俺爹去的很早,我过去的时候书已经木有了,主要是去收拾东西了,把一些有用没用的继续整理,基本上三楼的就处理完毕了,舒了一大口气,毕竟让丈母娘一个人收拾实在是太累了,但是要扔掉的衣服比较棘手,附近知道的青蛙回收桶被推倒了,其他地方也不知道哪里有,我们就先载了一些东西去在修的房子那,然后去找青蛙桶,结果一个小区可以进,但是已经满了,另一个不让进,后来只能让 LD 姐姐带去她们小区扔了,塞了满满一车。因为要赶回杭州的车就没有等我爸一起回来,他还在那帮忙搞卫生间的墙缝。
虽然这两天不太热,活也不算很吃力,不过我这个体重和易出汗的体质,还是让短袖不知道湿透了多少次,灌了好多水和冰红茶(下午能提提神),回来周一早上称体重也比较喜人,差一点就达到阶段目标,可以想想去哪里吃之前想好的烤肉跟火锅了(估计吃完立马回到解放前)。
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl |
安装完成就会自动启动Caddy,
这时我们就可以来实践反向代理,并且自带https,
caddy reverse-proxy --from :2080 --to :9000 |
这样就可以构建一个2080到9000的反向代理
如果需要做域名的反向代理
可以这样
caddy reverse-proxy --from example.com --to :9000 |
可以在本地开启一个9000端口的http服务
php -S localhost:9000 |
然后请求本地
curl -v https://localhost |
就能看到响应
* Trying 127.0.0.1:443... |
然后在php侧服务器就能看到
[Sun Oct 6 21:34:29 2024] PHP 8.1.2-1ubuntu2.19 Development Server (http://localhost:9000) started |
还能用配置的形式
|
再运行caddy reload就能启动,还是很方便的
]]>ER模型,全称为实体联系模型、实体关系模型或实体联系模式图(ERM)(英语:Entity-relationship model)由美籍华人计算机科学家陈品山发明,是概念数据模型的高层描述所使用的数据模型或模式图。
常规上的理解ER图分为三个部分,
第一个是实体,也就是ER图的E,表示Entity
第二个是属性,表示Entity中带有的属性,比如以学生表为例,它有姓名,性别,年龄,年纪等等属性
第三个核心的是关系,也就是ER图例的R,表示Relationship,比如学生表跟班级表是怎么样的关系,一般情况下一个学生一定属于一个班级,那么学生和班级的关系就是多对一的关系
对于画ER图,比较推荐使用Draw.io来画,开源免费且功能强大
它左边菜单栏就自带了ER图的组件
我们就可以直接拖动组件来画出ER图
这样就能画出简单的ER图了,并且连1对1,1对多这种关系都有现成的连线组件了,真的是治愈强迫症,如果自己画这个N对N的线,老是会觉得画得不一致而感觉画的不好看
而且还有一个很强大的功能,比如我们在画ER图的时候已经把表结构设计好了,那么就能直接从表结构生成ER图
可以在这里导入表结构sql,就能生成对应的实体图了,如果有外键关联还会生成对应的连接,当然手动加一下也很方便了
其中加载部分可以认为是初始的部分,我们可以从各个数据源去获取信息,比如各种文档,或者confluence,甚至api接口,只需要合适的数据加载器,我们就能将其转化为我们要的数据
比如我想要将我博客里的Markdown文件作为知识库加载
reader = SimpleDirectoryReader( |
然后由文档来就构建我们的索引
index = VectorStoreIndex.from_documents(docs) |
但是这里我们需要提前设置好对应的 embedding 模型,这个很重要,如果有条件推荐使用OpenAI的,如果想用本地的可以考虑使用BAAI智源出品的,只是要注意是否支持多语言,如果要使用本地embedding的话需要安装
pip install llama-index-embeddings-huggingface |
这里我选了BAAI也就是智源研究所的bge-m3模型,因为这个是支持多语言的,如果是纯英文的可以用他们 BAAI/bge-small-en-v1.5
from llama_index.core import Settings |
另外LLM 我使用了本地部署的 gemma:7b,因为想尝试下本地的链路,需要注意的是一些文档还是用的原来的service_context,在新版本中这个已经被改掉了,都是通过 Settings 来设置,此外还有诸如 SimpleDirectoryReader 这些包也被挪到了 llama_index.core 中,需要注意下
然后我们就能使用这种方式来增强LLM,把我们的本地文档作为知识库来搜索,结合了大模型的能力。
CREATE TABLE IF NOT EXISTS `students` ( |
假设我们有如下学生数据,我想找到每个班年纪最大的学生,可以用一些联表或者子查询方法
| id | name | age | class |
|---|---|---|---|
| 1 | 学生1 | 10 | 1 |
| 2 | 学生2 | 10 | 2 |
| 3 | 学生3 | 11 | 1 |
| 4 | 学生3 | 11 | 2 |
在MySQL 8.0之前,我们需要使用相对复杂的子查询配合JOIN来实现:
SELECT ta.* |
分析:
子查询阶段:SELECT class, MAX(age) as max_age FROM students GROUP BY class
{class: 1, max_age: 20}, {class: 2, max_age: 21}JOIN阶段:将原表与子查询结果关联
ta.class = tb.class AND ta.age = tb.max_age局限性:
MySQL 8.0引入了窗口函数,让这类问题的解决变得更加优雅:
SELECT * FROM ( |
核心概念解析:
PARTITION BY class:按班级进行分区
ORDER BY age DESC:在每个分区内按年龄降序排序
**ROW_NUMBER()**:为每个分区内的行分配唯一序号
外层WHERE row_num = 1:筛选每个分区的第一条记录
除了ROW_NUMBER(),还可以根据业务需求选择其他窗口函数:
-- 使用RANK():相同值会有相同排名,但会跳跃序号 |
ROW_NUMBER()确保每个分组只返回一条记录PERCENT_RANK()等函数ROWS BETWEEN进行滑动窗口计算MySQL 8.0的窗口函数为分组排序查询提供了更现代化的解决方案。相比传统的子查询+JOIN方式,窗口函数不仅在语法上更加简洁直观,在性能上也有显著提升。对于需要在分组内进行复杂数据分析的场景,窗口函数已经成为不可或缺的利器。
]]>Flexible AI workflow automation
for technical teams
根据中文教程的描述,它也可以认为是个低代码的画布工具,首先安装非常简单,咱们先玩玩本地的
前提是装有docker
然后就三个命令
docker pull n8nio/n8n |
就安装好了,本地端口就是5678
在浏览器打开 http://localhost:5678/ 就可以看到了,我模仿中文的教程来记录下简单的工作流搭建流程,抓取即刻的帖子
第一步我们先建第一个节点,这个类似于是开关,怎么触发这个工作流,
这里也能初步看出n8n的强大,可以通过各种方式来触发,我们就先选一个手动触发
然后我们还需要能获取http内容的,
我们就添加一个http组件,通过搜索http,可以找到http的请求工具
这里我们只需要填入地址
比如跟教程中的一样 https://m.okjike.com/users/6d3698d6-0970-49a6-a19d-f8d3cfa33a6f,
然后就是要把请求的内容解析出来
搜索html,我们就可以找到解析html内容的工具
从网页中找到对应的选择器,记得勾选 return array,否则只会取第一个
执行下当前组件,就能看到内容已经被抓下来了
接下去要分割下,选择 Data transformation 的工具中的split out
然后就把前面的正文和时间和拖进去
最后就是导出文件了
搜索 xlsx,然后出现convert to file工具,然后把对应的字段拖进去
非常直观和方便的就完成了一个简单的工作流搭建,当然这个还没用上AI工具,大模型和MCP等,但是已经把它的很多特点都介绍了,各种工具真的非常好用和傻瓜化
没有复杂难搞的配置和调试,对于一些文字处理表格处理真的很方便
后续我们再来看下怎么跟大模型接起来,让它更加的强大。
但是你说这不是个灾难片,而是个反映社会问题的,就业比较容易往这个方向猜,只是剧情会是怎么样的,一时也没啥头绪,后来不知道哪里看了下一个剧情透露,是一个穷人给富人做家教,然后把自己一家都带进富人家,如果是这样的话可能会把这个怎么带进去作为一个主线,不过事实告诉我,这没那么重要,从第一步朋友的介绍,就显得无比顺利,要去当家教了,作为一个穷成这样的人,瞬间转变成一个衣着得体,言行举止都没让富人家看出破绽的延世大学学生,这真的挺难让人理解,所谓江山易改,本性难移,还有就是这人也正好有那么好能力去辅导,并且诡异的是,多惠也是瞬间就喜欢上了男主,多惠跟将男主介绍给她做家教,也就是多惠原来的家教敏赫,应该也有不少的相处时间,这变了有点大了吧,当然这里也可能因为时长需要,如果说这一点是因为时长,那可能我所有的槽点都是因为这个吧,因为我理解的应该是把家里的人如何一步步地带进富人家,这应该是整个剧情的一个需要更多铺垫去克服这个矛盾点,有时候也想过如果我去当导演,是能拍出个啥,没这个机会,可能有也会是很扯淡的,当然这也不能阻拦我谈谈对这个点的一些看法,毕竟评价一台电冰箱不是说我必须得自己会制冷对吧,这大概是我觉得这个电影的第一个槽点,接下去接二连三的,就是我说的这个最核心的矛盾点,不知道谁说过,这种影视剧应该是源自于生活又高于生活,越是好的作品,越要接近生活,这样子才更能有感同身受。
接下去的点是金基宇介绍金基婷去给多颂当美术家教,这一步又是我理解的败笔吧,就怎么说呢,没什么铺垫,突然从一个社会底层的穷姑娘,转变成一个气场爆表,把富人家太太唬得一愣一愣的,如果说富太太是比较简单无脑的,那富人自己应该是比较有见识而且是做 IT 的,给自己儿子女儿做家教的,查查底细也很正常吧,但是啥都没有,然后呢,她又开始耍司机的心机了,真的是莫名其妙了,司机真的很惨,窈窕淑女君子好逑,而且这个操作也让我摸不着头脑,这是多腹黑并且有经验才会这么操作,脱内裤真的是让我看得一愣愣的,更看得我一愣一愣的,富人竟然也完全按着这个思路去想了,完全没有别的可能呢,甚至可以去查下行车记录仪或者怎样的,或者有没有毛发体液啥的去检验下,毕竟金基婷也乘坐过这辆车,但是最最让我不懂的还是脱内裤这个操作,究竟是什么样的人才会的呢,值得思考。
金基泽和忠淑的点也是比较奇怪,首先是金基泽,引起最后那个杀人事件的一个由头,大部分观点都是人为朴社长在之前跟老婆啪啪啪的时候说金基泽的身上有股乘地铁的人的味道,简而言之就是穷人的味道,还有去雯光丈夫身下拿钥匙是对金基泽和雯光丈夫身上的味道的鄙夷,可是这个原因真的站不住脚,即使是同样经济水平,如果身上有比较重的异味,背后讨论下,或者闻到了比较重的味道,有不适的表情和动作很正常吧,像雯光丈夫,在地下室里呆了那么久,身上有异味并且比较重太正常了,就跟在厕所呆久了不会觉得味道大,但是从没味道的地方一进有点味道的厕所就会觉得异样,略尴尬的理由;再说忠淑呢,感觉是太厉害了,能胜任这么一家有钱人的各种挑剔的饮食口味要求的保姆职位,也是让人看懵逼了,看到了不禁想到一个问题,这家人开头是那么地穷,不堪,突然转变成这么地像骗子家族,如果有这么好的骗人能力,应该不会到这种地步吧,如果真的是那么穷,没能力,没志气,又怎么会突然变成这么厉害呢,一家人各司其职,把富人家唬得团团转,而这个前提是,这些人的确能胜任这四个位置,这就是我非常不能理解的点。
然后说回这个标题,寄生虫,不知道是不是翻译过来不准确,如果真的是叫寄生虫的话,这个寄生虫智商未免也太低了,没有像新冠那样机制,致死率低一点,传染能力强一点,潜伏期也能传染,这个寄生虫第一次受到免疫系统的攻击就自爆了;还有呢,作为一个社会比较低层的打工者,乡下人,对这个审题也是不太审的清,是指这一家人是社会的寄生虫,不思进取,并且死的应该,富人是傻白甜,又有钱又善良,这是给有钱人洗地了还是啥,这个奥斯卡真不知道是怎么得的,总觉得奥斯卡,甚至低一点,豆瓣,得奖的,评分高的都是被一群“精英党”把持的,有黑人主角的,得分高;有同性恋的,得分高;结局惨的,得分高;看不懂的,得分高;就像肖申克的救赎,真不知道是哪里好了,最近看了关于明朝那些事的三杨,杨溥的经历应该比这个厉害吧,可是外国人看不懂,就像外国人不懂中国为什么有反分裂国家法,经历了鸦片战争,八国联军,抗日战争等等,其实跟外国对于黑人的权益的问题,因为有南北战争,所以极度重视这个问题,相应的中国也有自己的历史,请理解。
简而言之我对寄生虫的评分大概 5~6 分吧。
]]>
|
首先是通过arp记录内网ip地址,然后添加UPLOAD和DOWNLOAD链,
然后为mac-arp文件中每个ip地址添加FORWARD规则,将流量导到UPLOAD和DOWNLOAD链
等待1秒,统计下载和上传速度,计算KB/s,packets/s,再清理规则
然后对于上传占用高的,我们可以用
iptables -t mangle -I FORWARD 1 -s 192.168.x.x -m limit --limit 800/s --limit-burst 1000 -j ACCEPT |
限制通过包的数量为800,不过这个不绝对精确
]]>termux-change-repo来更改包的安装源termux-setup-storage |
然后我们去到 /storage/emulated/0 目录下,就发现安卓的文件就在这个目录下,举个例子这样我们就可以用脚本来处理我的照片文件
第三点是其实目前的手机处理器性能已经到了一个非常不错的阶段,比如我看了下我的渣渣安卓机是高通骁龙870处理器,它是个21年出的手机处理器,性能大致接近于桌面端i5 4590
870的geekbench跑分,单核1141,多核3317
i5 4590的geekbench跑分,单核1142,3165
单核非常接近,多核还稍微领先,并且最近也看到有用最新的高通骁龙8gen3来跑端侧大模型的,其实说明了目前手机的性能真的达到了很高的水平,提供了更多的可玩性,虽然从另一个角度来讲,870在运行现在最新版本的手机应用时会发烫变卡,那是因为手机应用往往要做非常多的事情,后台保活,前台的各种图形渲染,包括微信,支付宝都有了内置的小程序,那么都需要一套资源隔离机制来实现运行态的维护,并且各种内容也搞得花里胡哨都需要资源,我们只是运行简单的脚本,手机的可用性不比很多云服务器差,一般云服务器我们个人用户都买的是比较低配的,最低1核1g的配置,远不如现在的手机强大,可玩性是真的不错的。
pip install towhee towhee.models |
这里有第一个坑,因为有torch依赖,但是目前torch支持的python版本是最高3.9,再往上可能就有问题了
所以我们要先创建一个3.9的环境
conda create -n py9 python=3.9 |
然后我们会遇到第二个坑
就是milvus的客户端
pip install pymilvus==2.3.0 |
再早的客户端会有依赖不支持,更新的客户端会连接不上
然后再在milvus创建一个Collection
然后这个是不对的,因为我使用attu界面创建的,默认第二个字段一定得是向量字段,所以又用了上次的Java代码来创建
CreateCollectionReq.CollectionSchema collectionSchema = clientV2.createSchema(); |
并且注意字段顺序不能错,这个顺序在towhee的demo中也没地方直接修改
看一下towhee的demo
地址在这
https://towhee.io/tasks/detail/pipeline/text-image-search
from towhee import AutoPipes, AutoConfig |
第三个坑,这并不能跑起来
embedding = insert_pipe.image_embedding('./test.jpg').get()[0] |
因为找不到这个 image_embedding
估计是这个也是包路径变更了,但是并没有什么文档可以找到,之前LlamaIndex还有点更新指南,后来是问了Claude才知道了
from towhee import AutoPipes, AutoConfig, ops |
需要从 AutoPipes 中把这个 image-embedding 找出来
然后就是上面说到的字段映射问题,默认是先url,再embedding字段,并且主键字段必须是autoId,不然也会缺少默认值,还是感叹下,工程化的东西还是要工程化的质量保证,否则变更都无从知晓,现在人工智能大热,大家都在追风,只是基础的软件还是要稳扎稳打,这样我们工程人员才能把它们更好的用起来,PS:娃真可爱,但真的好累
<!-- 仓库定义 --> |
然后增加依赖
<dependencyManagement> |
引入主要的几个包
<dependency> |
代码也很简单,但是不确定是api限流太严重还是啥,响应慢的离谱
|
对的,甚至把prompt写死了
这里经过了好几个包版本的调整
原先比较早的0.8的不支持接口的自定义路径,因为要用火山的接口,它的接口跟openai是不一样的,后面有个v3啥的
所以需要增加最下面一行
spring.ai.openai.base-url=https://ark.cn-beijing.volces.com/api/v3 |
但是可以从上面的图里看出来,响应非常慢,简直不能忍,有openai 权限的可以帮忙试下究竟是啥原因,抓包啥的也不太方便
]]>时光飞逝,我在初中高中的时候因为爱打篮球,以为自己体质已经有了质的变化,所以在体育课跑步的时候妄图跟一位体育非常好的同学一起跑,结果跟的快断气了,最终还是确认了自己是个体育渣,特别是到了大学的第一次体测跑一千米,跑完直接吐了,一则是大学太宅不运动,二则的确是底子不好。那么怎么会去跑步了呢,其实也没什么特殊的原因,就是工作以后因为运动得更少,体质差,而且越来越胖,所以就想运动下,加之跑步也是我觉得成本最低的运动了,刚好那时候17 年租的地方附近小区周围的路车不太多,一圈刚好一公里多,就觉得开始跑跑看,其实想想以前觉得一千米是非常远的,学校塑胶跑道才 400 米,一千米要两圈半,太难了,但是后来在这个小区周围跑的时候好像跑了一圈以后还能再跑一点,最后跑了两圈,可把自己牛坏了,我都能跑两千米了,哈哈,这是个什么概念呢,大学里最让我绝望的两项体育相关的内容就是一千米和十二分钟跑,一千米把我跑吐了,十二分钟跑及格五圈半也能让我跑完花一周时间恢复以及提前一周心理压力爆炸,虽然我那时候跑的不快,但是已经能跑两千米了,瞬间让自己自信心爆炸,并且跑完步出完汗的感觉是非常棒的,毕竟吃奶茶鸡排都能心安理得了,谁叫我跑步了呢😄,其实现在回去看,那时候跑得还算快的,因为还比较瘦,现在要跑得那么快心跳就太快了,关于心跳什么的后面说,开始建立起自信心之后,对跑步这件事就开始不那么排斥跟害怕了,毕竟我能跑两千米了,然后试试三公里,哇,也可以了呢,三公里是什么概念呢,我大学里跑过最多的一次是十二分钟跑五圈半还是六圈,也就是两公里多,不到三公里,几乎是生涯最长了,一时间产生了一些我可能是个被埋没的运动天才的错觉,其实细想下也能明白,只是速度足够慢了就能跑多一点,毕竟提测一千米是要跑进四分钟才及格,自己跑的时候一千米跑六分多钟已经算不慢了(对我自己来说),但是即使是这样还是对把跑步坚持下去这件事有了很大的正面激励作用,并且由于那时候上下班骑车,整个体重控制的比较理想,导致一时间误会跑步就能非常快的减肥(其实这是我跑步历程中比较大的误区之一),因为会在跑步前后称下体重,如果跑个五公里(后面可以跑五公里了),可能体重就能降 0.5 千克,但实际上这只是这五公里跑步身体流失的水分,喝杯水就回来了,那时候能控制体重主要是骑车跟跑步一起的作用,并且工作压力相对来讲比较小,没有过劳肥。
后面其实跑步慢慢变得一个比较习惯的运动了,从三公里,到五公里,到七公里,再到十公里,十公里差不多对我来说是个坎,一直还不能比较轻松的跑十公里,可能近一两年好了一些(原谅我只是跟自己比较,跟那些大神比差得不知道多远),其实对我来说每次都是个突破,因为其实与他人比较没有特别大意义,比较顶尖的差得太远,比较普通的也不行,都会打击自信心,比较比我差的就更没意义了,所以其实能挑战自己,能把自己的上限提高才是最有意义的,这也是我看着朋友圈里的一些大神的速度除了佩服赞叹之外没什么其他的惭愧或者说嫌弃自己的感觉(阿 Q 精神😄)。
一直感性地觉得,跑步能解压,跑完浑身汗,有种把身体的负能量都排出去的感觉,也把吃太多的罪恶感排解掉了🤦♂️,之前朋友有看一本书,书名差不多叫越跑越接近自己,这个也是我觉得挺准确的一句话,当跑到接近极限了,还想再继续再跑一点,再跑一点就能突破自己上一次的最远记录了,再跑一点就能又一次突破自己了,成人以后,毕业以后,进入社会以后,世事总是难以件件顺遂,磕磕绊绊的往前走,总觉得要崩溃了,但是还是得坚持,再熬一下,再拼一下,可能还是失败,但人生呢,运气好的人和事总是小概率的,唯有面对挫折,还是日拱一卒,来日方长,我们再坚持下,没准下一次,没准再跑一会,就能突破自己,达到新的境界。
另外个人后期对跑步的一些知识和理解也变得深入一些,比如伤膝盖,其实跑步的确伤膝盖,需要做一些准备和防护,最好的是适合自己的跑鞋和比较好的路(最好的是塑胶跑道了),也要注意热身跟跑后的拉伸(虽然我做的很差),还有就是注意心率,每个人有自己的适宜心率,我这就不冒充科普达人了,可以自行搜索关键字,先说到这吧~
]]>https://www.alipan.com/s/sd4Wi6TDzeP |
第一步打开USB Burning Tool, 要短接刷入update.img
通过文件导入网盘里的 update.img,然后先用双公头USB线连接电脑的USB口和玩客云靠近HDMI口的USB口,如果方便最好接到电脑后置的USB口,防止不稳定刷机终端,接下来就需要短接了,这里的姿势要先短接好,保持稳定,然后插上电源线,这里如果连接成功就会在软件左上会显示一栏连接成功,如果电脑连接音响也会有叮咚这样的声音,接下去就可以点开始进行刷入底包了,这里最大的困难点就是保持短接稳定后插电源,并且继续保持稳定刷入底包,底包刷入会比较快,等到刷机进度条走完刷成功后就点停止,然后关闭软件,拔掉玩客云电源,拔掉USB
第二步是刷入Armbian系统,根据一些教程有些说需要先刷入5.8,我这边是直接刷入了5.9的系统,也就多一步,准备一个U盘,16G或者8G都行,先用Etcher把5.8系统刷入U盘,刷入完成后再关闭软件,推出U盘,将U盘插入玩客云上靠近网口的USB口,然后再通电,指示灯会蓝色-> 绿色 -> 蓝紫闪烁 -> 蓝色,这样就是刷机成功了,会需要一点时间,刷机完成后再把5.9的的刷入U盘,再继续刚才的步骤,此时需要把网线插入玩客云,等待正常亮灯显示后,在路由器上可以找到一个aml-s812的设备,在通过ssh连接,账号是root,密码是1234,进入系统后通过以下命令就可以刷入emmc了
cd /boot/install sudo ./install.sh |
完成后会自动断开,拔掉U盘后再用同样方法连接就可以了,后续怎么使用就是Linux相关的了,后面也可以讲下docker的操作,但要注意架构,这个是arm架构32位的
]]>玩客云这样的小机器现在也有一些自己的生态了,感谢开源大佬们的贡献,这个casaos就是个颜值颇高的轻nas方案,casaos虽然叫做os,但其实一套轻nas组件,并且有一个好看的webui,然后通过docker来作为内部的软件市场安装形式,我们沿着上一篇接下来尝试下安装轻度试用下这个casaos,首先安装
|
安装会提示空间不够大,可以先忽略,如果想更保险的话就可以通过加一张SD卡或者USB插外接硬盘
安装中主要是执行了casaos的一些安装shell,以及启动rclone服务,完成后给出了登录地址,默认是80端口,可以在后面UI界面里更改端口

也可以设置自动挂载usb

安装完以后打开地址

创建账户

进入系统后的UI长这样

还是挺赏心悦目的,默认会展示系统的状态,cpu,内存和存储网络这些,预装了syncthing作为同步工具,还有个App Store
有挺多应用在商店
只是这里就会发现个问题,只是玩客云是32为的ArmV7系统

有很多组件不支持,包括jellyfin这些,不过它提供了自定义安装功能,可以自定义安装docker镜像

不过这里有个小bug,拷贝镜像名进入第一个输入框以后会提示不能为空,这边需要带上tag一起复制进去

第二个问题是我安装的0.4.8是没办法安装latest以外的tag的,不然会提示 store app not found
在dockerhub上是有armv7版本的jellyfin的,只是没有latest这个tag的,如果实在想体验下就考虑安装casaos的0.4.7或更早先版本的或者可以自己在Armbian里拉取镜像再安装下Portainer来管理docker,不过玩客云的性能是真的很羸弱,所以不要抱什么期望,低负载的任务可以跑跑,jellyfin显然不是很合适的,只是作为一个示例
逻辑复杂负载比较高的就算了,考虑N1或者其他性能更好的机器
]]>iptables -Liptables -L 显示不了mangle table的规则这个一直是属于一知半解的状态,知道 utf8 跟 utf8mb4 的区别主要是能不能支持 emoji,但是具体后面配置的排序规则是用来干嘛,或者有什么区别,应该使用哪个,所以在 stackoverflow 上找了下,有两个比较不错的解答,就搬过来并且配合机翻做了点修改
For those people still arriving at this question in 2020 or later, there are newer options that may be better than both of these. For example, utf8mb4_0900_ai_ci.
All these collations are for the UTF-8 character encoding. The differences are in how text is sorted and compared.
_unicode_ci and _general_ci are two different sets of rules for sorting and comparing text according to the way we expect. Newer versions of MySQL introduce new sets of rules, too, such as _0900_ai_ci for equivalent rules based on Unicode 9.0 - and with no equivalent _general_ci variant. People reading this now should probably use one of these newer collations instead of either _unicode_ci or _general_ci. The description of those older collations below is provided for interest only.
MySQL is currently transitioning away from an older, flawed UTF-8 implementation. For now, you need to use utf8mb4 instead of utf8 for the character encoding part, to ensure you are getting the fixed version. The flawed version remains for backward compatibility, though it is being deprecated.
Key differences
utf8mb4_unicode_ci is based on the official Unicode rules for universal sorting and comparison, which sorts accurately in a wide range of languages.
utf8mb4_general_ci is a simplified set of sorting rules which aims to do as well as it can while taking many short-cuts designed to improve speed. It does not follow the Unicode rules and will result in undesirable sorting or comparison in some situations, such as when using particular languages or characters.
On modern servers, this performance boost will be all but negligible. It was devised in a time when servers had a tiny fraction of the CPU performance of today’s computers.
Benefits of utf8mb4_unicode_ci over utf8mb4_general_ci
utf8mb4_unicode_ci, which uses the Unicode rules for sorting and comparison, employs a fairly complex algorithm for correct sorting in a wide range of languages and when using a wide range of special characters. These rules need to take into account language-specific conventions; not everybody sorts their characters in what we would call ‘alphabetical order’.
As far as Latin (ie “European”) languages go, there is not much difference between the Unicode sorting and the simplified utf8mb4_general_cisorting in MySQL, but there are still a few differences:
For examples, the Unicode collation sorts “ß” like “ss”, and “Œ” like “OE” as people using those characters would normally want, whereas utf8mb4_general_cisorts them as single characters (presumably like “s” and “e” respectively).
Some Unicode characters are defined as ignorable, which means they shouldn’t count toward the sort order and the comparison should move on to the next character instead. utf8mb4_unicode_cihandles these properly.
In non-latin languages, such as Asian languages or languages with different alphabets, there may be a lot more differences between Unicode sorting and the simplified utf8mb4_general_cisorting. The suitability of utf8mb4_general_ciwill depend heavily on the language used. For some languages, it’ll be quite inadequate.
What should you use?
There is almost certainly no reason to use utf8mb4_general_cianymore, as we have left behind the point where CPU speed is low enough that the performance difference would be important. Your database will almost certainly be limited by other bottlenecks than this.
In the past, some people recommended to use utf8mb4_general_ciexcept when accurate sorting was going to be important enough to justify the performance cost. Today, that performance cost has all but disappeared, and developers are treating internationalization more seriously.
There’s an argument to be made that if speed is more important to you than accuracy, you may as well not do any sorting at all. It’s trivial to make an algorithm faster if you do not need it to be accurate. So, utf8mb4_general_ciis a compromise that’s probably not needed for speed reasons and probably also not suitable for accuracy reasons.
One other thing I’ll add is that even if you know your application only supports the English language, it may still need to deal with people’s names, which can often contain characters used in other languages in which it is just as important to sort correctly. Using the Unicode rules for everything helps add peace of mind that the very smart Unicode people have worked very hard to make sorting work properly.
What the parts mean
Firstly, ci is for case-insensitive sorting and comparison. This means it’s suitable for textual data, and case is not important. The other types of collation are cs (case-sensitive) for textual data where case is important, and bin, for where the encoding needs to match, bit for bit, which is suitable for fields which are really encoded binary data (including, for example, Base64). Case-sensitive sorting leads to some weird results and case-sensitive comparison can result in duplicate values differing only in letter case, so case-sensitive collations are falling out of favor for textual data - if case is significant to you, then otherwise ignorable punctuation and so on is probably also significant, and a binary collation might be more appropriate.
Next, unicode or general refers to the specific sorting and comparison rules - in particular, the way text is normalized or compared. There are many different sets of rules for the utf8mb4 character encoding, with unicode and general being two that attempt to work well in all possible languages rather than one specific one. The differences between these two sets of rules are the subject of this answer. Note that unicode uses rules from Unicode 4.0. Recent versions of MySQL add the rulesets unicode_520 using rules from Unicode 5.2, and 0900 (dropping the “unicode_” part) using rules from Unicode 9.0.
And lastly, utf8mb4 is of course the character encoding used internally. In this answer I’m talking only about Unicode based encodings.
对于那些在 2020 年或之后仍会遇到这个问题的人,有可能比这两个更好的新选项。例如,utf8mb4_0900_ai_ci。
所有这些排序规则都用于 UTF-8 字符编码。不同之处在于文本的排序和比较方式。
_unicode_ci和 _general_ci是两组不同的规则,用于按照我们期望的方式对文本进行排序和比较。较新版本的 MySQL 也引入了新的规则集,例如 _0900_ai_ci用于基于 Unicode 9.0 的等效规则 - 并且没有等效的 _general_ci变体。现在阅读本文的人可能应该使用这些较新的排序规则之一,而不是 _unicode_ci或 _general_ci。下面对那些较旧的排序规则的描述仅供参考。
MySQL 目前正在从旧的、有缺陷的 UTF-8 实现过渡。现在,您需要使用 utf8mb4 而不是 utf8作为字符编码部分,以确保您获得的是固定版本。有缺陷的版本仍然是为了向后兼容,尽管它已被弃用。
主要区别
utf8mb4_unicode_ci基于官方 Unicode 规则进行通用排序和比较,可在多种语言中准确排序。
utf8mb4_general_ci是一组简化的排序规则,旨在尽其所能,同时采用许多旨在提高速度的捷径。它不遵循 Unicode 规则,并且在某些情况下会导致不希望的排序或比较,例如在使用特定语言或字符时。
在现代服务器上,这种性能提升几乎可以忽略不计。它是在服务器的 CPU 性能只有当今计算机的一小部分时设计的。
utf8mb4_unicode_ci 相对于 utf8mb4_general_ci的优势
utf8mb4_unicode_ci使用 Unicode 规则进行排序和比较,采用相当复杂的算法在多种语言中以及在使用多种特殊字符时进行正确排序。这些规则需要考虑特定语言的约定;不是每个人都按照我们所说的“字母顺序”对他们的字符进行排序。
就拉丁语(即“欧洲”)语言而言,Unicode 排序和 MySQL 中简化的 utf8mb4_general_ci排序没有太大区别,但仍有一些区别:
例如,Unicode 排序规则将“ß”排序为“ss”,将“Œ”排序为“OE”,因为使用这些字符的人通常需要这些字符,而 utf8mb4_general_ci将它们排序为单个字符(大概分别像“s”和“e” )。
一些 Unicode 字符被定义为可忽略,这意味着它们不应该计入排序顺序,并且比较应该转到下一个字符。 utf8mb4_unicode_ci正确处理这些。
在非拉丁语言中,例如亚洲语言或具有不同字母的语言,Unicode 排序和简化的 utf8mb4_general_ci排序之间可能存在更多差异。 utf8mb4_general_ci的适用性在很大程度上取决于所使用的语言。对于某些语言,这将是非常不充分的。
你应该用什么?
几乎可以肯定没有理由再使用 utf8mb4_general_ci,因为我们已经将 CPU 速度低到会严重影响性能表现的时代远抛在脑后了。您的数据库几乎肯定会受到除此之外的其他瓶颈的限制。
过去,有些人建议使用 utf8mb4_general_ci,除非准确排序足够重要以证明性能成本是合理的。如今,这种性能成本几乎消失了,开发人员正在更加认真地对待国际化。
有一个论点是,如果速度对您来说比准确性更重要,那么您可能根本不进行任何排序。如果您不需要准确的算法,那么使算法更快是微不足道的。因此,utf8mb4_general_ci是一种折衷方案,出于速度原因可能不需要,也可能出于准确性原因也不适合。
我要补充的另一件事是,即使您知道您的应用程序仅支持英语,它可能仍需要处理人名,这些人名通常包含其他语言中使用的字符,在这些语言中正确排序同样重要.对所有事情都使用 Unicode 规则有助于让您更加安心,因为非常聪明的 Unicode 人员已经非常努力地工作以使排序正常工作。
其余各个部分是什么意思
首先, ci 用于不区分大小写的排序和比较。这意味着它适用于文本数据,大小写并不重要。其他类型的排序规则是 cs(区分大小写),用于区分大小写的文本数据,以及 bin,用于编码需要匹配的地方,逐位匹配,适用于真正编码二进制数据的字段(包括,用于例如,Base64)。区分大小写的排序会导致一些奇怪的结果,区分大小写的比较可能会导致重复值仅在字母大小写上有所不同,因此区分大小写的排序规则对文本数据不受欢迎 - 如果大小写对您很重要,那么标点符号就可以忽略等等可能也很重要,二进制排序规则可能更合适。
接下来,unicode 或general 指的是具体的排序和比较规则——特别是文本被规范化或比较的方式。 utf8mb4 字符编码有许多不同的规则集,其中 unicode 和 general 是两种,它们试图在所有可能的语言中都很好地工作,而不是在一种特定的语言中。这两组规则之间的差异是此答案的主题。请注意,unicode 使用 Unicode 4.0 中的规则。 MySQL 的最新版本使用 Unicode 5.2 的规则添加规则集 unicode_520,使用 Unicode 9.0 的规则添加 0900(删除“unicode_”部分)。
最后,utf8mb4 当然是内部使用的字符编码。在这个答案中,我只谈论基于 Unicode 的编码。
UTF-8is a variable-length encoding. In the case of UTF-8, this means that storing one code point requires one to four bytes. However, MySQL’s encoding called “utf8” (alias of “utf8mb3”) only stores a maximum of three bytes per code point.
So the character set “utf8”/“utf8mb3” cannot store all Unicode code points: it only supports the range 0x000 to 0xFFFF, which is called the “Basic Multilingual Plane“. See also Comparison of Unicode encodings.
This is what (a previous version of the same page at)the MySQL documentationhas to say about it:
The character set named utf8[/utf8mb3] uses a maximum of three bytes per character and contains only BMP characters. As of MySQL 5.5.3, the utf8mb4 character set uses a maximum of four bytes per character supports supplemental characters:
- For a BMP character, utf8[/utf8mb3] and utf8mb4 have identical storage characteristics: same code values, same encoding, same length.
- For a supplementary character, utf8[/utf8mb3] cannot store the character at all, while utf8mb4 requires four bytes to store it. Since utf8[/utf8mb3] cannot store the character at all, you do not have any supplementary characters in utf8[/utf8mb3] columns and you need not worry about converting characters or losing data when upgrading utf8[/utf8mb3] data from older versions of MySQL.
So if you want your column to support storing characters lying outside the BMP (and you usually want to), such as emoji, use “utf8mb4”. See also What are the most common non-BMP Unicode characters in actual use?.
UTF-8 是一种可变长度编码。对于 UTF-8,这意味着存储一个代码点需要一到四个字节。但是,MySQL 的编码称为“utf8”(“utf8mb3”的别名)每个代码点最多只能存储三个字节。
所以字符集“utf8”/“utf8mb3”不能存储所有的Unicode码位:它只支持0x000到0xFFFF的范围,被称为“基本多语言平面”。另请参阅 Unicode 编码比较。
这就是(同一页面的先前版本)MySQL 文档 不得不说的:
名为 utf8[/utf8mb3] 的字符集每个字符最多使用三个字节,并且仅包含 BMP 字符。从 MySQL 5.5.3 开始,utf8mb4 字符集每个字符最多使用四个字节,支持补充字符:
- 对于 BMP 字符,utf8[/utf8mb3] 和 utf8mb4 具有相同的存储特性:相同的代码值、相同的编码、相同的长度。
- 对于补充字符,utf8[/utf8mb3] 根本无法存储该字符,而 utf8mb4 需要四个字节来存储它。由于 utf8[/utf8mb3] 根本无法存储字符,因此您在 utf8[/utf8mb3] 列中没有任何补充字符,您不必担心从旧版本升级 utf8[/utf8mb3] 数据时转换字符或丢失数据mysql。
因此,如果您希望您的列支持存储位于 BMP 之外的字符(并且您通常希望这样做),例如 emoji,请使用“utf8mb4”。另请参阅
]]>conda create -n open_manus python=3.12 |
然后来clone下代码仓库
git clone https://github.com/mannaandpoem/OpenManus.git |
接着再安装下依赖
pip install -r requirements.txt |
这里可以借助下源替换加速,临时使用可以这样子 pip install -i https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple some-package , 这里需要安装蛮久的,可能也说明了这是个依赖于很多现成库的工具
配置其实也是常规的,依赖于大模型,那么要不就是自己部署提供api,要不就是去火山引擎或者其他大模型api提供商搞个api(免费额度用完要自己付费的)
cp config/config.example.toml config/config.toml |
这一步其实跟之前使用chatbox连接火山的配置类似
因为像国外很多都还是openai的接口服务,这边就需要改用成国内可用的
[llm] |
模型可以用deepseek-r1,不过要注意是什么时间版本的,否则也会访问不到
然后我们就可以运行
python main.py |
来运行openmanus,我们简单问个问题
明天杭州的天气怎么样,给出个穿衣指南 |
看下结果
python main.py |
根据这个返回可以看到它做了些啥,主要是规划步骤和选择调用的工具,相对来说没有特别的,playwright我就不去搞了,浏览器那套
]]>https://github.com/mannaandpoem/OpenManusBaseTool 的新工具类Manus类的available_tools定义,将您的工具添加到默认工具列表ollama run gemma:7b |
这里需要拉取模型,约5.2g 大小,考虑网络原因可能会比较慢
我们可以简单来试试问个问题

看出来回答的还是比较丰富的,谷歌出品还是比较有水平的,不至于像 ChatGLM 最初版本的在不做调优的情况下甚至有点前言不搭后语
对于想使用 chatgpt 但是没条件,这也算是个低配平替了, 并且已经是个比较可用的了,同时也方便进行学习调优等
如果想要类似于 chatgpt 那样的网页版,可以安装 open-webui
可以通过 webui 访问 ollama 运行的大模型,
用 docker 启动的命令也贴一下
docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main |
不过有个小问题就是 docker 镜像拉取会有点慢,可以添加下国内镜像加速
{ |

这里有一个小区别,Gemma 在多轮会话的时候会在前面的答案基础上再完善。
补充一个在 windows 环境下,cpu 跑模型的也是可行的
现在是大模型可以深入千家万户了,大家都可以尝试下,如果对日常的工作学习有一些效率上的提升也是好的
io.netty.handler.codec.http.HttpServerCodec
pipeline.addLast(new HttpServerCodec()); |
它继承了 io.netty.channel.CombinedChannelDuplexHandler
public HttpServerCodec(HttpDecoderConfig config) { |
在初始化的时候调用了 io.netty.channel.CombinedChannelDuplexHandler#init
传入参数
public HttpServerCodec(HttpDecoderConfig config) { |
这个 HttpServerRequestDecoder
private final class HttpServerRequestDecoder extends HttpRequestDecoder { |
这个decode方法就会调用到父类的decode方法 io.netty.handler.codec.http.HttpObjectDecoder#decode
protected void decode(ChannelHandlerContext ctx, ByteBuf buffer, List<Object> out) throws Exception { |
这个方法里会做实际的byte转换成message或者说string的转换
而在我们把消息转换完成,
会在最后加一个 io.netty.handler.codec.http.LastHttpContent#EMPTY_LAST_CONTENT
这样其实我的message就会变成两条,也就是为啥channelRead0会被调用两次,这样的目的也是让我的业务代码可以分辨是否请求已经读完,并且可以在读完以后有一些其他操作空间
可以看到第一次调用channelRead0的msg
第二次就是
public static void main(String[] args) throws InterruptedException { |
然后来看下 HttpServerInitializer
public class HttpServerInitializer extends ChannelInitializer<SocketChannel> { |
实际的代码也是很简略,我们用一个hello world统一响应所有的请求
public class SimpleHttpServerHandler extends SimpleChannelInboundHandler<HttpObject> { |
上面就是这个简单的示例了,只是我在 channelRead0 入口建了个打印,但是这个再接收请求时会打印两次,可以作为个探讨题,我们下次来分析下
尝试保持一个比较冷静的状态来聊聊,在看的时候有一点感想就是如果要剧里的坏人排个名,因为明眼看都是孙兴是个穷凶极恶的坏人,干尽了坏事,而且可能是演员表演地好,让人真的恨的牙痒痒,但是更多地还是停留在那些剧情中的表现和他的表情,其实对应的真实案例有更多的,这里尽量不展开,有兴趣可以自行搜索关键字,所以其实我想排个名的话,孙兴的母亲应该是我心目中是造成这个结果的比较大占比的始作俑者,因为是方方面面的,包括对林汉的栽赃迫害,最后串起来是因为他看到了孙兴又出来了,就是那句老话,撒了一个谎以后就要用无数个谎来圆,贺芸为了孙兴,作了第一个恶以后就用了一系列的丧心病狂的操作来保护孙兴,而且这之后所做的事情一件比一件可怕,并且如果不是督导组各种想方设法地去破解谜题,这个事情还可以一直被通过各种操作瞒下去,而孙兴还可以继续地为虎作伥,当然其他的包括高明远以及后面的王政,当然是为了这个操作也提供的各种方式的帮助,甚至是主导了这些操作,但是这里贺芸还是在这个位子上能够通过权力做出非常关键的动作,包括栽赃林汉,并且搞掉了李成阳。其中还有一点是我对剧情设计的质疑,也是我前面提到过一点,因为里面孙兴好像是很爱他的母亲贺芸,似乎想表达的是孙兴作的恶是因为得不到母爱,并且个人感觉如果是一个比较敬爱自己母亲的儿子,似乎应该有所畏惧,对他的行为也会有所限制,不应该变成这样一个无恶不作的恶霸,这也是我一直以来的观点,很多人作恶太多可能是因为没有信仰,不管是信基督耶稣还是信道教佛教,总归有一些制约,当然不是说就绝对不会作恶,只是偏向于有所畏惧敬畏,除了某绿哈。
而对于其他的人感觉演技都不错,只是最后有一些虎头蛇尾吧,不知道是不是审核的原因,也不细说了怕被请喝茶,还有提一点就是麦佳的这个事情,她其实是里面很惨的一个人,把高明远当成最亲近的人,而其实真相令人感觉不寒而栗,杀父杀母的仇人,对于麦佳这个演员,一直觉得印象深刻,后来才想起来就是在爱情公寓里演被关谷救了要以身相遇的那个女孩,长相其实蛮令人印象深刻的,但好像也一直不温不火,不过也不能说演技很好吧,只是在这里演的任务真的是很可怜了,剧情设计里也应该是个很重要的串联人物,最终被高明远献给了大佬,这里扯开一点,好像有的观点说贺芸之前也是这样的,只是一种推测了。
看完这部剧其实有很多想说的,但是也为了不被请喝茶,尽量少说了,只想说珍爱生命,还是自己小心吧
]]>ollama run gemma3:1b |
然后对应的配置是
<dependency> |
当然这里有个坑,因为目前还不成熟,所以这个包的依赖跟之前openai的是不兼容的
需要引用
<dependency> |
属性配置就很简单了
spring.ai.ollama.base-url=http://localhost:11434 |
然后就是简单写个Controller就可以了
|
这样我们的初始调用就完成了
比如我们提问 ‘how to learn java’
Okay, let's break down how to learn Java! It can seem daunting at first, but with a structured approach, you'll be coding in Java in no time. Here’s a breakdown of a recommended learning path, broken down into phases: **1. Foundation (2-4 Weeks)** * **Understand the Basics:** * **What is Java?** Java is a robust, object-oriented programming language known for its platform independence ("write once, run anywhere"). It’s used for enterprise applications, Android development, and more. * **Why Learn Java?** It’s a popular choice for beginners because it’s relatively easy to learn, has a large community, and is used in many real-world applications. * **Key Concepts:** * **Variables & Data Types:** Understand different data types (int, float, String, boolean, etc.). * **Operators:** Arithmetic, comparison, logical, assignment. * **Control Flow:** `if`, `else`, `for`, `while` – controlling the flow of your program. * **Basic Syntax:** The code structure of Java. * **Resources:** * **Tutorialspoint Java Course:** [https://www.tutorialspoint.com/java/index.htm](https://www.tutorialspoint.com/java/index.htm) - A good, comprehensive, and free overview. * **Codecademy's Learn Java:** [https://www.codecademy.com/learn/learn-java](https://www.codecademy.com/learn/learn-java) - Interactive, hands-on exercises. * **Google's Java Tutorial:** [https://developer.android.com/training/jdbc](https://developer.android.com/training/jdbc) (Java is built on JDBC, so this will give you a baseline) **2. Core Concepts (4-8 Weeks)** * **Data Structures:** * **Arrays:** Fundamental data structures. Understand how to declare, initialize, and use arrays. * **Linked Lists:** Another essential data structure, offering flexibility. * **Object-Oriented Programming (OOP) Fundamentals:** * **Classes and Objects:** The basis of OOP. Learn how to define classes, create objects, and interact with them. * **Encapsulation:** Bundling data and methods that operate on that data within a class. * **Inheritance:** Creating new classes based on existing classes. * **Polymorphism:** The ability of objects to take on many forms. * **Java Syntax & Semantics:** * **Statements:** The commands you write. * **Expressions:** Results of calculations. * **Keywords:** Reserved words with special meanings (e.g., `class`, `if`, `else`). * **Comments:** Explain your code. * **Resources:** * **Oracle Java Tutorials:** [https://docs.oracle.com/javase/tutorial/](https://docs.oracle.com/javase/tutorial/) – A more in-depth guide. * **FreeCodeCamp's Java Tutorial:** [https://www.freecodecamp.org/learn/java-tutorial/](https://www.freecodecamp.org/learn/java-tutorial/) - Great for visual learners. **3. Practical Application - Projects** * **Simple Programs:** Start with small, manageable projects: * **Number Guessing Game:** A classic introductory project. * **Rock-Paper-Scissors:** A basic example of OOP. * **Simple Calculator:** Reinforces fundamental concepts. * **Gradually Increase Complexity:** * **Print Statements:** A simple way to understand output. * **Palindrome Checker:** A challenge to practice string manipulation. * **Basic Console Applications:** Write programs that run directly in the console. **4. Intermediate Concepts (Ongoing)** * **Exception Handling:** Understanding and handling errors. * **Collections:** Learn about ArrayLists, LinkedLists, Sets, and Maps. * **String Manipulation:** Working with strings effectively. * **Multithreading:** Understanding how to run multiple tasks concurrently (basic concepts). * **Java Collections Framework:** The cornerstone of modern Java programming. **Resources for Continued Learning:** * **Stack Overflow:** [https://stackoverflow.com/](https://stackoverflow.com/) - An invaluable resource for solving coding problems and learning from others. * **Reddit's r/java:** [https://www.reddit.com/r/java/](https://www.reddit.com/r/java/) - A community forum with discussions and resources. * **YouTube:** Search for Java tutorials and courses (e.g., "Java for beginners"). **Tips for Success:** * **Practice Regularly:** Even 30 minutes a day is better than long, infrequent sessions. * **Write Code Frequently:** The more you write, the better you'll understand. * **Don't Be Afraid to Make Mistakes:** Mistakes are part of the learning process. Learn from them. * **Read Code:** Look at code written by others to understand different approaches. * **Join a Community:** Connecting with others can provide support and motivation. **To help me tailor my advice even more, could you tell me:** * **What's your background in programming?** (e.g., Have you programmed before? If so, what languages?) * **What are your goals for learning Java?** (e.g., Career change? Personal project? Specific application like Android?) |
格式不太美观,但是至少是能输出来结果了,而且可以选择本地可用的最佳模型,话说openai的oss试了下,本地有点吃不消,不然可能是比较合适的
]]>├─────────────────────────────────┤
│ │
│ ┌─────────────────────────┐ │
│ │ 上下文容器 │ │
│ │ ┌─────────────────┐ │ │
│ │ │ 对话历史 │ │ │
│ │ └─────────────────┘ │ │
│ │ ┌─────────────────┐ │ │
│ │ │ 系统指令 │ │ │
│ │ └─────────────────┘ │ │
│ │ ┌─────────────────┐ │ │
│ │ │ 用户背景 │ │ │
│ │ └─────────────────┘ │ │
│ └─────────────────────────┘ │
│ │
│ ┌─────────────────────────┐ │
│ │ 控制参数 │ │
│ └─────────────────────────┘ │
│ │
│ ┌─────────────────────────┐ │
│ │ 消息体 │ │
│ └─────────────────────────┘ │
│ │
└─────────────────────────────────┘
首先基于start.spring.io创建一个springboot应用,需要springboot的版本3.3+和jdk17+
然后添加maven依赖
<dependency> |
我们就可以实现一个mcp的demo server
package com.nicksxs.mcp_demo; |
通过 api.weather.gov 来请求天气服务,给出结果
然后通过一个客户端来访问请求下
public static void main(String[] args) { |
这个就是实现了mcp的简单示例,几个问题,要注意java的多版本管理,我这边主要是用jdk1.8,切成 17需要对应改maven的配置等
]]>电驴看的比较草率,主要是考虑续航,然后锂电池外加 48v 和 24AH,这样一般来讲还是价格比较高的,只是原来没预料到这个限速,以为现在的车子都比较快,但是现在的新国标车子都是 25km/h 的限速,然后 15km/h 都是会要提醒,虽然说有一些特殊的解除限速的方法,但是解了也就 35km/h ,差距不是特别大,而且现在的车子都是比较小,也不太能载东西,特别是上下班路程也不远的情况下,其实不是那么需要速度,就像我朋友说的,可能骑车的时间还不如等红绿灯多,所以就还好,也不打算解除限速,只是品牌上也仔细看,后来选了绿源,目前大部分还是雅迪,爱玛,台羚,绿源,小牛等,路上看的话还是雅迪比较多,不过价格也比较贵一点,还有就是小牛了,是比较新兴的品牌,手机 App 什么的做得比较好,而且也比较贵,最后以相对比较便宜的价格买了个锂电 48V24AH 的小车子,后来发现还是有点不方便的点就是没有比较大的筐,也不好装,这样就是下雨天雨衣什么的比较不方便放。
聊回来主题上牌这个事情,这个事情也是颇费心力,提车的时候店里的让我跟他早上一起去,但是因为不确定时间,也比较远就没跟着去,因为我是线上买的,线下自提,线下的店可能没啥利润可以拿,就不肯帮忙代上牌,朋友说在线下店里买是可以代上的,自己上牌过程也比较曲折,一开始是头盔没到,然后是等开发票,主要的东西就是需要骑着车子去车管所,不能只自己去,然后需要预约,附近比较近的都是提前一周就预约完了号了,要提前在支付宝上进行预约,比较空的就是店里推荐的景区大队,但是随之而来就是比较蛋疼的,这个景区大队太远了,看下骑车距离有十几公里,所以就有点拖延症,但是总归要上的,不然一直不能开是白买了,上牌的材料主要是车辆合格证,发票,然后车子上的浙品码,在车架上和电池上,然后车架号什么的都要跟合格证上完全对应,整体车子要跟合格证上一毛一样,如果有额外的反光镜,后面副座都需要拆掉,脚踏板要装上,到了那其实还比较顺利,就是十几公里外加那天比较冷,吹得头疼。
]]>client在物理子网上发送广播来寻找可用的服务器。网络管理员可以配置一个本地路由来转发DHCP包给另一个子网上的DHCP服务器。该client实现生成一个目的地址为255.255.255.255或者一个子网广播地址的UDP包。
客户也可以申请它使用的最后一个IP地址(在下面的例子里为192.168.1.100)。如果该客户所在的网络中此IP仍然可用,服务器就可以准许该申请。否则,就要看该服务器是授权的还是非授权的。授权服务器会拒绝请求,使得客户立刻申请一个新的IP。非授权服务器仅仅忽略掉请求,导致一个客户端请求的超时,于是客户端就会放弃此请求而去申请一个新的IP地址。
当DHCP服务器收到一个来自客户的IP租约请求时,它会提供一个IP租约。DHCP为客户保留一个IP地址,然后通过网络单播一个DHCPOFFER消息给客户。该消息包含客户的MAC地址、服务器提供的IP地址、子网掩码、租期以及提供IP的DHCP服务器的IP。
服务器基于在CHADDR字段指定的客户硬件地址来检查配置。这里的服务器,192.168.1.1,将IP地址指定于YIADDR字段。
当客户PC收到一个IP租约提供时,它必须告诉所有其他的DHCP服务器它已经接受了一个租约提供。因此,该客户会发送一个DHCPREQUEST消息,其中包含提供租约的服务器的IP。当其他DHCP服务器收到了该消息后,它们会收回所有可能已提供给该客户的租约。然后它们把曾经给该客户保留的那个地址重新放回到可用地址池中,这样,它们就可以为其他计算机分配这个地址。任意数量的DHCP服务器都可以响应同一个IP租约请求,但是每一个客户网卡只能接受一个租约提供。
当DHCP服务器收到来自客户的REQUEST消息后,它就开始了配置过程的最后阶段。这个响应阶段包括发送一个DHCPACK包给客户。这个包包含租期和客户可能请求的其他所有配置信息。这时候,TCP/IP配置过程就完成了。
该服务器响应请求并发送响应给客户。整个系统期望客户来根据选项来配置其网卡。
客户端向DHCP服务器发送一个请求以释放DHCP资源,并注销其IP地址。鉴于客户端更多的时候并不清楚何时用户会将其从网络中移除,此协议不会托管“DHCP释放的发送”。
服务器回复客户,客户要求的IP不能被分配。
而对于Ubuntu,现在较新版本的设置方式也有点变化,比如我用的是22.04
cd /etc/netplan/ |
先去这个目录下查看配置文件
我们要找的是这个 00-installer-config.yaml 文件
原本的是长这样
默认是通过dhcp分配ip
我们要改成静态ip
network: |
解释一下 ethernets中的ens33表示我们的网卡接口的标识
可以通过 ip addr 查看
第一个是本地回环,第二个可以看下是否跟内网ip对应上,如果是的话就这个ens33
然后就是addresses填的地址,就是我们想要固定的ip地址,记得得是自己局域网网段的
上面只是个示例,然后是nameservers里的是dns服务器,也是按需填写
这里的114.114.114.114跟233.5.5.5分别是电信跟阿里云的,仅供参考
然后是routes就是网关地址,按自己的环境填写,网络没有任何特殊处理的一般就是路由器
接下去就是应用这个配置
sudo netplan apply |
这样ip配置就生效了
可以通过ip addr show ens33查看
ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy 它是继承了 ch.qos.logback.core.rolling.TimeBasedRollingPolicystart 方法
public void start() { |
配置了 timeBasedFileNamingAndTriggeringPolicy 策略
然后调用了父类的启动方法,主要看下父类的
public void start() { |
第一步是给 renameUtil 设置 context
第二步是判断 fileNamePatternStr是否已配置,没配置会报错,如果配置了就会去判断压缩格式,是否要压缩以及压缩的是 gz 还是 zip
第三步就是设置压缩器了
第四步是判断文件后缀格式,注意是不带压缩格式的
第五步是判断 timeBasedFileNamingAndTriggeringPolicy 是否已设置,这里是在子类里已经设置了 ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP 否则就是 ch.qos.logback.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy 这个默认的
第六步比较重要就是启动 timeBasedFileNamingAndTriggeringPolicy
timeBasedFileNamingAndTriggeringPolicy 的启动逻辑里首先是调用了 SizeAndTimeBasedFNATP 的 start 方法,然后里面最开始调用了父类的 start
public void start() { |
也就是下面的代码
public void start() { |
前面是日期时区等配置处理,然后是判断按日期生成的文件会不会冲突,接下去是设置当前时间段,如果配置了日志文件的话就会把当前时间段设置成已有的日志文件的最后更改时间,最后的 computeNextCheck 比较重要
主要是下面的方法
protected void computeNextCheck() { |
会按照我们设置的 FileNamePattern 中的 datePattern 来推断 periodicityType,比如我们是小时滚动的,那就是 TOP_OF_HOUR ,算出来下一个时间检查点,后面会按这个判断是否作为触发事件触发日志滚动更新
父类的 start 逻辑讲完以后,子类的其实比较简单,先判断使用方式,我们这是嵌入式的,然后是父类有没有产生错误,继续是最大文件大小是否设置了,再判断日期格式是否正常,然后是归档移除类的创建,并设置到上下文中,然后计算当前时间的最大日志文件计数器,最后判断是否报错,没有的话就启动成功了
]]>logger.info("log some thing and biz info: {}",biz); |
这里就调用了ch.qos.logback.classic.Logger#info(java.lang.String, java.lang.Object)
public void info(String format, Object arg) { |
这里的 FQCN 就是这个类的全限定名
public static final String FQCN = ch.qos.logback.classic.Logger.class.getName(); |
这个具体的 filterAndLog_1 方法还是在同一个 Logger 类里的ch.qos.logback.classic.Logger#filterAndLog_1
private void filterAndLog_1(final String localFQCN, final Marker marker, final Level level, final String msg, final Object param, final Throwable t) { |
这里面先是走过滤器逻辑,如果是拒绝的,那就不往下执行,也就不执行下面的写日志逻辑了,如果是中性的,那就判断日志级别是否符合,如果直接是拒绝就 return 了,如果是 ACCEPT 就往下执行了
public enum FilterReply { |
然后继续调用同样的类的方法ch.qos.logback.classic.Logger#buildLoggingEventAndAppend
private void buildLoggingEventAndAppend(final String localFQCN, final Marker marker, final Level level, final String msg, final Object[] params, |
先把日志包装成 LoggingEvent ,然后调用ch.qos.logback.classic.Logger#callAppenders
public void callAppenders(ILoggingEvent event) { |
这里会按 Logger 调用 appendLoopOnAppenders
private int appendLoopOnAppenders(ILoggingEvent event) { |
继续调用事件的ch.qos.logback.core.spi.AppenderAttachableImpl#appendLoopOnAppenders
public int appendLoopOnAppenders(E e) { |
因为 Logger 里有关联 appender,就具体调用关联的 appender 来添加日志
然后就接着调用ch.qos.logback.core.UnsynchronizedAppenderBase#doAppend 方法
public void doAppend(E eventObject) { |
这里先判断了 guard 的状态,guard 是个 ThreadLocal,是为了拦截异常的无限循环调用,这里有些疑惑的,看了一圈可能相关的是前面的 Logger 会往父级查找,然后如果不同层级的 Logger 关联了相同的 appender 的话,或者这个 doAppend 又被其他 appender 调用了,就可能会出现循环调用,然后会在开始实际的 append的之前先设置 guard 状态,
然后再执行 append,这里会走到ch.qos.logback.core.OutputStreamAppender#append
|
忘了补充下,我们这里使用的是ch.qos.logback.core.rolling.RollingFileAppender
接下去就是调用的 RollingFileAppender 的 subAppend 方法
|
这里就会先判断是否触发事件,
而这里就是主要的逻辑,看是否需要走 rollover,也就是具体的滚动逻辑
|
这里主要就用到了 nextCheck 判断,如果通过判断就可以执行滚动了,然后就是后面的判断,是否太快了,也就是 isTooSoon 然后再看当前的活跃日志以及最大文件大小是否设置,然后如果当前的活跃日志的大小超过了配置也会触发滚动
]]>private static final Log logger = LogFactory.getLog(SpringApplication.class); |
然后是
public static Log getLog(Class clazz) throws LogConfigurationException { |
继续下去是org.apache.commons.logging.impl.SLF4JLogFactory#getInstance(java.lang.Class)
public Log getInstance(Class clazz) throws LogConfigurationException { |
然后再往下处理就是 LoggerFactory.getLogger(name); 了,跟普通的获取 logger 一样
public static Logger getLogger(String name) { |
继续下去会先判断是否已初始化
public static ILoggerFactory getILoggerFactory() { |
第一次调用的话就会走到 org.slf4j.LoggerFactory#performInitialization 里面是先调用绑定,这也是 slf4j 门面模式的特点
private final static void performInitialization() { |
private final static void bind() { |
非安卓环境会进入第一个 if 逻辑,先要去找static_logger_binder
static Set<URL> findPossibleStaticLoggerBinderPathSet() { |
上面的 STATIC_LOGGER_BINDER_PATH
就是 org/slf4j/impl/StaticLoggerBinder.class 如果找不到在外层方法就会抛出 NoSuchMethodError 错误,然后就是通过 StaticLoggerBinder.getSingleton(); 获取 StaticLoggerBinder 实例了
public static StaticLoggerBinder getSingleton() { |
比较重要的是这里的 static 代码块还有一个逻辑,就是下面这个初始化逻辑
static { |
上面的 defaultLoggerContext 也是通过静态代码块处理的
private LoggerContext defaultLoggerContext = new LoggerContext(); |
然后是调用 ch.qos.logback.classic.util.ContextInitializer#autoConfig 方法
public void autoConfig() throws JoranException { |
前面会先查找配置文件路径URL url = findURLOfDefaultConfigurationFile(true); 还是调用这个类内的 ch.qos.logback.classic.util.ContextInitializer#findURLOfDefaultConfigurationFile 方法
public URL findURLOfDefaultConfigurationFile(boolean updateStatus) { |
才发现原来这里也是硬编码了文件名
public class ContextInitializer { |
如果不为空就调用了ch.qos.logback.classic.util.ContextInitializer#configureByResource 这边是根据后缀判断处理方法
public void configureByResource(URL url) throws JoranException { |
因为我们找到的是 logback.xml,所以走的是ch.qos.logback.classic.joran.JoranConfigurator ,
然后调用了ch.qos.logback.core.joran.GenericConfigurator#doConfigure(java.net.URL)
这个 GenericConfigurator 是 JoranConfigurator 的父类
public final void doConfigure(URL url) throws JoranException { |
然后继续调用ch.qos.logback.core.joran.GenericConfigurator#doConfigure(java.io.InputStream, java.lang.String) 处理具体的内容,前面处理了内容获取,因为如果是走的 url 文件就需要从网络获取文件流,
public final void doConfigure(InputStream inputStream, String systemId) throws JoranException { |
而实际的处理 xml 内容则是在ch.qos.logback.core.joran.GenericConfigurator#doConfigure(org.xml.sax.InputSource)
public final void doConfigure(final InputSource inputSource) throws JoranException { |
需要解析 xml 了,先是调用 buildInterpreter 构建了 Interpreter
public void doConfigure(final List<SaxEvent> eventList) throws JoranException { |
build 里还有一些逻辑,就是匹配后面要处理的规则集,就是要确认那些标签要处理
protected void buildInterpreter() { |
第一步就是先 new 一个 ch.qos.logback.core.joran.spi.SimpleRuleStore 然后调用了 ch.qos.logback.classic.joran.JoranConfigurator#addInstanceRules 来添加规则,就是下面的,可以看到对于 logger,appender 这些的配置,其中前面点的父类也又一些规则 ,ch.qos.logback.core.joran.JoranConfiguratorBase 逻辑类似就不展开了,这里的规则就对应了后面的各种 Action,就是对应的处理逻辑
public void addInstanceRules(RuleStore rs) { |
然后调用了 interpreter 的 eventPlayer 处理 xml 的各个标签
public void play(List<SaxEvent> aSaxEventList) { |
接下去就在 startElement 中调用会先获取 getApplicableActionList 适配的 Action, callBeginAction
private void startElement(String namespaceURI, String localName, String qName, Attributes atts) { |
里面就是用了 ruleStore 来判断是否适配,并且取出对应的 Action
List<Action> getApplicableActionList(ElementPath elementPath, Attributes attributes) { |
比如我这边往下处理,通过规则匹配拿到了 LoggerAction, 然后调用 Action.begin 方法
void callBeginAction(List<Action> applicableActionList, String tagName, Attributes atts) { |
就是下面这个
public void begin(InterpretationContext ec, String name, Attributes attributes) { |
这里就会处理 logger 获取逻辑
public final Logger getLogger(final String name) { |
如果从 loggerCache 中能取到就直接获取,如果不能就会去创建
public static void main(String[] args) { |
入口的代码时这样子,其实主要的逻辑在createNamesrvController和start方法,来看下这两个的实现
public static NamesrvController createNamesrvController(String[] args) throws IOException, JoranException { |
这个方法里其实主要是读取一些配置啥的,不是很复杂,
public static NamesrvController start(final NamesrvController controller) throws Exception { |
这个start里主要关注initialize方法,后面就是一个停机的hook,来看下initialize方法
public boolean initialize() { |
这里的kvConfigManager主要是来加载NameServer的配置参数,存到org.apache.rocketmq.namesrv.kvconfig.KVConfigManager#configTable中,然后是以BrokerHousekeepingService对象为参数初始化NettyRemotingServer对象,BrokerHousekeepingService对象作为该Netty连接中Socket链接的监听器(ChannelEventListener);监听与Broker建立的渠道的状态(空闲、关闭、异常三个状态),并调用BrokerHousekeepingService的相应onChannel方法。其中渠道的空闲、关闭、异常状态均调用RouteInfoManager.onChannelDestory方法处理。这个BrokerHousekeepingService可以字面化地理解为broker的管家服务,这个类内部三个状态方法其实都是调用的org.apache.rocketmq.namesrv.NamesrvController#getRouteInfoManager方法,而这个RouteInfoManager里面的对象有这些
public class RouteInfoManager { |
然后接下去就是初始化了一个线程池,然后注册默认的处理类this.registerProcessor();默认都是这个处理器去处理请求 org.apache.rocketmq.namesrv.processor.DefaultRequestProcessor#DefaultRequestProcessor然后是初始化两个定时任务
第一是每10秒检查一遍Broker的状态的定时任务,调用scanNotActiveBroker方法;遍历brokerLiveTable集合,查看每个broker的最后更新时间(BrokerLiveInfo.lastUpdateTimestamp)是否超过2分钟,若超过则关闭该broker的渠道并调用RouteInfoManager.onChannelDestory方法清理RouteInfoManager类的topicQueueTable、brokerAddrTable、clusterAddrTable、filterServerTable成员变量。
this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { |
第二个是每10分钟打印一次NameServer的配置参数。即KVConfigManager.configTable变量的内容。
this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() { |
然后这个初始化就差不多完成了,后面只需要把remotingServer start一下就好了
直接上代码,其实主体是swtich case去判断
|
以broker注册为例,
case RequestCode.REGISTER_BROKER: |
做了个简单的版本管理,我们看下前面一个的代码
public RemotingCommand registerBrokerWithFilterServer(ChannelHandlerContext ctx, RemotingCommand request) |
可以看到主要的逻辑还是在org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager#registerBroker这个方法里
public RegisterBrokerResult registerBroker( |
这个是注册 broker 的逻辑,再看下根据 topic 获取 broker 信息和 topic 信息,org.apache.rocketmq.namesrv.processor.DefaultRequestProcessor#getRouteInfoByTopic 主要是这个方法的逻辑
public RemotingCommand getRouteInfoByTopic(ChannelHandlerContext ctx, |
首先调用org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager#pickupTopicRouteData从org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager#topicQueueTable获取到org.apache.rocketmq.common.protocol.route.QueueData这里面存了 brokerName,再通过org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager#brokerAddrTable里获取到 broker 的地址信息等,然后再获取 orderMessage 的配置。
简要分析了下 RocketMQ 的 NameServer 的代码,比较粗粒度。
]]>read(file, tmp_buf, len); |

如上面的图显示的,要在用户态跟内核态进行切换,数据还需要在内核缓冲跟用户缓冲之间拷贝多次,
- 第一步是调用 read,需要在用户态切换成内核态,DMA模块从磁盘中读取文件,并存储在内核缓冲区,相当于是第一次复制
- 数据从内核缓冲区被拷贝到用户缓冲区,read 调用返回,伴随着内核态又切换成用户态,完成了第二次复制
- 然后是write 写入,这里也会伴随着用户态跟内核态的切换,数据从用户缓冲区被复制到内核空间缓冲区,完成了第三次复制,这次有点不一样的是数据不是在内核缓冲区了,会复制到 socket buffer 中。
- write 系统调用返回,又切换回了用户态,然后数据由 DMA 拷贝到协议引擎。
如此就能看出其实默认的读写操作代价是非常大的,而在 rocketmq 等高性能中间件中都有使用的零拷贝技术,其中 rocketmq 使用的是 mmap
mmap基于 OS 的 mmap 的内存映射技术,通过MMU 映射文件,将文件直接映射到用户态的内存地址,使得对文件的操作不再是 write/read,而转化为直接对内存地址的操作,使随机读写文件和读写内存相似的速度。
mmap 把文件映射到用户空间里的虚拟内存,省去了从内核缓冲区复制到用户空间的过程,文件中的位置在虚拟内存中有了对应的地址,可以像操作内存一样操作这个文件,这样的文件读写文件方式少了数据从内核缓存到用户空间的拷贝,效率很高。
tmp_buf = mmap(file, len); |

]]>第一步:mmap系统调用使得文件内容被DMA引擎复制到内核缓冲区。然后该缓冲区与用户进程共享,在内核和用户内存空间之间不进行任何拷贝。
第二步:写系统调用使得内核将数据从原来的内核缓冲区复制到与套接字相关的内核缓冲区。
第三步:第三次拷贝发生在DMA引擎将数据从内核套接字缓冲区传递给协议引擎时。
通过使用mmap而不是read,我们将内核需要拷贝的数据量减少了一半。当大量的数据被传输时,这将有很好的效果。然而,这种改进并不是没有代价的;在使用mmap+write方法时,有一些隐藏的陷阱。例如当你对一个文件进行内存映射,然后在另一个进程截断同一文件时调用写。你的写系统调用将被总线错误信号SIGBUS打断,因为你执行了一个错误的内存访问。该信号的默认行为是杀死进程并dumpcore–这对网络服务器来说不是最理想的操作。
有两种方法可以解决这个问题。
第一种方法是为SIGBUS信号安装一个信号处理程序,然后在处理程序中简单地调用返回。通过这样做,写系统调用会返回它在被打断之前所写的字节数,并将errno设置为成功。让我指出,这将是一个糟糕的解决方案,一个治标不治本的解决方案。因为SIGBUS预示着进程出了严重的问题,所以不鼓励使用这种解决方案。
第二个解决方案涉及内核的文件租赁(在Windows中称为 “机会锁”)。这是解决这个问题的正确方法。通过在文件描述符上使用租赁,你与内核在一个特定的文件上达成租约。然后你可以向内核请求一个读/写租约。当另一个进程试图截断你正在传输的文件时,内核会向你发送一个实时信号,即RT_SIGNAL_LEASE信号。它告诉你内核即将终止你对该文件的写或读租约。在你的程序访问一个无效的地址和被SIGBUS信号杀死之前,你的写调用会被打断了。写入调用的返回值是中断前写入的字节数,errno将被设置为成功。下面是一些示例代码,显示了如何从内核中获得租约。
if(fcntl(fd, F_SETSIG, RT_SIGNAL_LEASE) == -1) {
perror("kernel lease set signal");
return -1;
}
/* l_type can be F_RDLCK F_WRLCK */
if(fcntl(fd, F_SETLEASE, l_type)){
perror("kernel lease set type");
return -1;
}
public static void main(String[] args) throws InterruptedException, MQClientException { |
然后就是看看 start 的过程了
/** |
具体的逻辑在this.defaultMQPushConsumerImpl.start(),这个 defaultMQPushConsumerImpl 就是
/** |
public synchronized void start() throws MQClientException { |
然后我们往下看主要的目光聚焦mQClientFactory.start()
public void start() throws MQClientException { |
我们来看下这个 pullMessageService,org.apache.rocketmq.client.impl.consumer.PullMessageService,
实现了 runnable 接口,
然后可以看到 run 方法
public void run() { |
接着在看 pullMessage 方法
private void pullMessage(final PullRequest pullRequest) { |
实际上调用了这个方法,这个方法很长,我在代码里注释下下每一段的功能
public void pullMessage(final PullRequest pullRequest) { |
以下就是拉取消息的底层 api,不够不是特别复杂,主要是在找 broker,和设置请求参数
public PullResult pullKernelImpl( |
再看下一步的
public PullResult pullMessage( |
通过 communicationMode 判断是同步拉取还是异步拉取,异步就调用
private void pullMessageAsync( |
并且会调用前面 pullCallback 的onSuccess和onException方法,同步的就是调用
private PullResult pullMessageSync( |
然后就是这个 remotingClient 的 invokeAsync 跟 invokeSync 方法
|
再往下看
public RemotingCommand invokeSyncImpl(final Channel channel, final RemotingCommand request, |
// ConsumeQueue file size,default is 30W |
所以文件大小是5.7M 左右

ConsumeQueue 的构建是通过org.apache.rocketmq.store.DefaultMessageStore.ReputMessageService运行后的 doReput 方法,而启动是的 reputFromOffset 则是通过org.apache.rocketmq.store.DefaultMessageStore#start中下面代码设置并启动
log.info("[SetReputOffset] maxPhysicalPosInLogicQueue={} clMinOffset={} clMaxOffset={} clConfirmedOffset={}", |
看一下 doReput 的逻辑
private void doReput() { |
分发的逻辑看到这
class CommitLogDispatcherBuildConsumeQueue implements CommitLogDispatcher { |
真正存储的是在这
private boolean putMessagePositionInfo(final long offset, final int size, final long tagsCode, |
这里也可以看到 ConsumeQueue 的存储格式,

偏移量,消息大小,跟 tag 的 hashCode
]]>CommitLog 是 rocketmq 的服务端,也就是 broker 存储消息的的文件,跟 kafka 一样,也是顺序写入,当然消息是变长的,生成的规则是每个文件的默认1G =1024 * 1024 * 1024,commitlog的文件名fileName,名字长度为20位,左边补零,剩余为起始偏移量;比如00000000000000000000代表了第一个文件,起始偏移量为0,文件大小为1G=1 073 741 824Byte;当这个文件满了,第二个文件名字为00000000001073741824,起始偏移量为1073741824, 消息存储的时候会顺序写入文件,当文件满了则写入下一个文件,代码中的定义
// CommitLog file size,default is 1G |

本地跑个 demo 验证下,也是这样,这里奇妙有几个比较巧妙的点(个人观点),首先文件就刚好是 1G,并且按照大小偏移量去生成下一个文件,这样获取消息的时候按大小算一下就知道在哪个文件里了,
代码中写入 CommitLog 的逻辑可以从这开始看
public PutMessageResult putMessage(final MessageExtBrokerInner msg) { |
前面也看到在CommitLog 目录下是有大小为 1G 的文件组成,在实现逻辑中,其实是通过 org.apache.rocketmq.store.MappedFileQueue ,内部是存的一个MappedFile的队列,对于写入的场景每次都是通过org.apache.rocketmq.store.MappedFileQueue#getLastMappedFile() 获取最后一个文件,如果还没有创建,或者最后这个文件已经满了,那就调用 org.apache.rocketmq.store.MappedFileQueue#getLastMappedFile(long)
public MappedFile getLastMappedFile(final long startOffset, boolean needCreate) { |
首先看下直接创建的,
public MappedFile(final String fileName, final int fileSize) throws IOException { |
如果是提交给AllocateMappedFileService的话就用到了一些异步操作
public MappedFile putRequestAndReturnMappedFile(String nextFilePath, String nextNextFilePath, int fileSize) { |
而真正去执行文件操作的就是 AllocateMappedFileService的 run 方法
public void run() { |
IndexFile 的构建则是分发给这个进行处理
class CommitLogDispatcherBuildIndex implements CommitLogDispatcher { |
配置的数量
private boolean messageIndexEnable = true; |
最核心的其实是 IndexFile 的结构和如何写入
public boolean putKey(final String key, final long phyOffset, final long storeTimestamp) { |
具体可以看一下这个简略的示意图
首先有一种情况是全局的有序,比如对于一个 topic 里就得发送线程保证只有一个,内部的 queue 也只有一个,消费线程也只有一个,这样就能比较容易的保证全局顺序性了,但是这里的问题就是完全限制了性能,不是很现实,在真实场景里很多都是比如对于同一个订单,需要去保证状态的轮转是按照预期的顺序来,而不必要全局的有序性。
对于这类的有序性,需要在发送和接收方都有对应的处理,在发送消息中,需要去指定 selector,即MessageQueueSelector,能够以固定的方式是分配到对应的 MessageQueue
比如像 RocketMQ 中的示例
SendResult sendResult = producer.send(msg, new MessageQueueSelector() { |
而在消费侧有几个点比较重要,首先我们要保证一个 MessageQueue只被一个消费者消费,消费队列存在broker端,要保证 MessageQueue 只被一个消费者消费,那么消费者在进行消息拉取消费时就必须向mq服务器申请队列锁,消费者申请队列锁的代码存在于RebalanceService消息队列负载的实现代码中。
List<PullRequest> pullRequestList = new ArrayList<PullRequest>(); |
在申请到锁之后会创建 pullRequest 进行消息拉取,消息拉取部分的代码实现在PullMessageService中,
|
消息拉取完后,需要提交到ConsumeMessageService中进行消费,顺序消费的实现为ConsumeMessageOrderlyService,提交消息进行消费的方法为ConsumeMessageOrderlyService#submitConsumeRequest,具体实现如下:
|
构建了一个ConsumeRequest对象,它是个实现了 runnable 接口的类,并提交给了线程池来并行消费,看下顺序消费的ConsumeRequest的run方法实现:
|
获取到锁对象后,使用synchronized尝试申请线程级独占锁。
如果加锁成功,同一时刻只有一个线程进行消息消费。
如果加锁失败,会延迟100ms重新尝试向broker端申请锁定messageQueue,锁定成功后重新提交消费请求
创建消息拉取任务时,消息客户端向broker端申请锁定MessageQueue,使得一个MessageQueue同一个时刻只能被一个消费客户端消费。
消息消费时,多线程针对同一个消息队列的消费先尝试使用synchronized申请独占锁,加锁成功才能进行消费,使得一个MessageQueue同一个时刻只能被一个消费客户端中一个线程消费。
这里其实还有很重要的一点是对processQueue的加锁,这里其实是保证了在 rebalance的过程中如果 processQueue 被分配给了另一个 consumer,但是当前已经被我这个 consumer 再消费,但是没提交,就有可能出现被两个消费者消费,所以得进行加锁保证不受 rebalance 影响。
public interface SmartLifecycle extends Lifecycle, Phased { |
接口继承了 org.springframework.context.Lifecycle 跟 org.springframework.context.Phased
其中默认实现了 isAutoStartup , 并且默认是返回 true,所以相对于 Lifecycle 能更智能些自动启动
然后 Lifecycle 这个接口就比较简单,只有几个接口
public interface Lifecycle { |
我们可以是实现下这个接口
|
这个 bean 会在 Spring 启动后被自动调用 start 方法
这个就是在不深入 bean 的生命周期,并且是在 bean 已经都初始化以后调用
同样会在 spring 容器关闭时调用 stop 方法
如果有此类的需求就可以扩展此接口实现
而这个其实是在 spring 生命周期中的 finishRefresh 方法中进行调用
protected void finishRefresh() { |
调用了 LifecycleProcessor 的 onRefresh 方法
public void onRefresh() { |
这其中就会调用 start 方法
private void startBeans(boolean autoStartupOnly) { |
会先判断 isAutoStartup,然后将不同周期加入分组,然后再循环调用start
|
而在 2.x 中变成了这样
|
为何会加载 AopAutoConfiguration 在前面的文章聊聊 SpringBoot 自动装配里已经介绍过,有兴趣的可以看下,可以发现 springboot 在 2.x 版本开始使用 cglib 作为默认的动态代理实现。
然后就是出现的问题了,代码是这样的,一个简单的基于 springboot 的带有数据库的插入,对插入代码加了事务注解,
|
第一个公有方法 createStudent 首先调用了 manager 层的创建方法,然后再通过引入的 studentService 调用了createStudent2,我们先跑一下看看会出现啥情况,果不其然报错了,正是这个报错让我纠结了很久

报了个空指针,而且是在 createStudent2 已经被调用到了,在它的内部,报的 studentManager 是 null,首先 cglib 作为动态代理它是通过继承的方式来实现的,相当于是会在调用目标对象的代理方法时调用 cglib 生成的子类,具体的代理切面逻辑在子类实现,然后在调用目标对象的目标方法,但是继承的方式对于 final 和私有方法其实是没法进行代理的,因为没法继承,所以我最开始的想法是应该通过 studentService 调用 createStudent2 的时候就报错了,也就是不会进入这个方法内部,后面才发现犯了个特别二的错误,继承的方式去调用父类的私有方法,对于 Java 来说是可以调用到的,父类的私有方法并不由子类的InstanceKlass维护,只能通过子类的InstanceKlass找到Java类对应的_super,这样间接地访问。也就是说子类其实是可以访问的,那为啥访问了会报空指针呢,这里报的是studentManager 是空的,可以往依赖注入方面去想,如果忽略依赖注入,我这个studentManager 的确是 null,那是不是就没有被依赖注入呢,但是为啥前面那个可以呢
这个问题着实查了很久,不废话来看代码
|
这个是org.springframework.aop.framework.CglibAopProxy.CglibMethodInvocation的代码,其实它在这里不是直接调用 super 也就是父类的方法,而是通过 methodProxy 调用 target 目标对象的方法,也就是原始的 studentService bean 的方法,这样子 spring 管理的已经做好依赖注入的 bean 就能正常起作用,否则就会出现上面的问题,因为 cglib 其实是通过继承来实现,通过将调用转移到子类上加入代理逻辑,我们在简单使用的时候会直接 invokeSuper() 调用父类的方法,但是在这里 spring 的场景里需要去支持 spring 的功能逻辑,所以上面的问题就可以开始来解释了,因为 createStudent 是公共方法,cglib 可以对其进行继承代理,但是在执行逻辑的时候其实是通过调用目标对象,也就是 spring 管理的被代理的目标对象的 bean 调用的 createStudent,而对于下面的 createStudent2 方法因为是私有方法,不会走代理逻辑,也就不会有调用回目标对象的逻辑,只是通过继承关系,在子类中没有这个方法,所以会通过子类的InstanceKlass找到这个类对应的_super,然后调用父类的这个私有方法,这里要搞清楚一个点,从这个代理类直接找到其父类然后调用这个私有方法,这个类是由 cglib 生成的,不是被 spring 管理起来经过依赖注入的 bean,所以是没有 studentManager 这个依赖的,也就出现了前面的问题
而在前面提到的cglib通过methodProxy调用到目标对象,目标对象是在什么时候设置的呢,其实是在bean的生命周期中,org.springframework.beans.factory.config.BeanPostProcessor#postProcessAfterInitialization这个接口的在bean的初始化过程中,会调用实现了这个接口的方法,
|
具体的逻辑在 org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator#wrapIfNecessary这个方法里
protected Object getCacheKey(Class<?> beanClass, String beanName) { |
然后在 org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator#createProxy 中创建了代理类
首先这里的场景跟我原来用的有点点区别,在项目中使用的是通过配置中心控制数据源切换,统一切换,而这里的例子多加了个可以根据接口注解配置
第一部分是最核心的,如何基于 Spring JDBC 和 Druid 来实现数据源切换,是继承了org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource 这个类,他的determineCurrentLookupKey方法会被调用来获得用来决定选择那个数据源的对象,也就是 lookupKey,也可以通过这个类看到就是通过这个 lookupKey 来路由找到数据源。
public class DynamicDataSource extends AbstractRoutingDataSource { |
而如何使用这个 lookupKey 呢,就涉及到我们的 DataSource 配置了,原来就是我们可以直接通过spring 的 jdbc 配置数据源,像这样

现在我们要使用 Druid 作为数据源了,然后配置 DynamicDataSource 的参数,通过 key 来选择对应的 DataSource,也就是下面配的 master1 和 master2
<bean id="master1" class="com.alibaba.druid.pool.DruidDataSource" init-method="init" |
现在就要回到头上,介绍下这个DatabaseContextHolder,这里使用了 ThreadLocal 存放这个 DatabaseType,为啥要用这个是因为前面说的我们想要让接口层面去配置不同的数据源,要把持相互隔离不受影响,就使用了 ThreadLocal,关于它也可以看我前面写的一篇文章聊聊传说中的 ThreadLocal,而 DatabaseType 就是个简单的枚举
public class DatabaseContextHolder { |
这边可以看到就是通过动态地通过putDatabaseType设置lookupKey来进行数据源切换,要通过接口注解配置来进行设置的话,我们就需要一个注解
|
这个注解可以配置在我的接口方法上,比如这样
public interface StudentService { |
通过切面来进行数据源的设置
|
通过接口判断是否带有注解跟是注解的值,DatabaseType 的配置不太好,不过先忽略了,然后在切点后进行清理
这是我 master1 的数据,

master2 的数据

然后跑一下简单的 demo,
|
看一下运行结果

其实这个方法应用场景不止可以用来迁移数据库,还能实现精细化的读写数据源分离之类的,算是做个简单记录和分享。
]]>这次碰到一个比较奇怪的问题,应该统一发布脚本统一给应用启动参数传了个 -Dserver.port=xxxx,其实这个端口会作为 dubbo 的服务端口,并且应用也不提供 web 服务,但是在启动的时候会报embedded servlet container failed to start. port xxxx was already in use就觉得有点奇怪,仔细看了启动参数猜测可能是这个问题,有可能是依赖的二方三方包带了 spring-web 的包,然后基于 springboot 的 auto configuration 会把这个自己加载,就在本地复现了下这个问题,结果的确是这个问题。
比较老的 springboot 版本,可以使用
SpringApplication app = new SpringApplication(XXXXXApplication.class); |
新版本的 springboot (>= 2.0.0)可以在 properties 里配置
spring.main.web-application-type=none |
或者
SpringApplication app = new SpringApplication(XXXXXApplication.class); |
这个枚举里还有其他两种配置
public enum WebApplicationType { |
相当于是把none 的类型和包括 servlet 和 reactive 放进了枚举类进行控制。
]]>https 我原本的理解来自于几个概念
第一个是非对称加密
也就是公钥可以公开在网上,然后用公钥加密,由私有的私钥进行解密,然后就对 https 有了初步的偏颇的概念,就是浏览器用公钥进行加密,服务器端用私钥进行解密,这里再仔细想想会延伸出来几个问题,也是逐步完善我的后续理解
第二个就是非对称加密以后的对称加密
因为对加密的理解是超大的质数(这个还来源于大学的数据结构老师)相乘后会很难做质因数分解,比如最大的质数2^82,589,933 − 1,用十进制表示有24,862,048位,用现在计算机来算也是非常难的,那如果一直采用非对称加密,这个效率也会比较低,所以在网上查了一番之后知道了是先采用非对称加密,然后再用对称加密,因为非对称加密先有了安全保证,后续的消息就可以用对称加密的方式来进行传输安全了
第三个是最近一次看到的
也是一直缺乏思考的问题,因为 https 我们在使用的时候都会购买证书或者使用免费的证书,那这个证书和前面说的公私钥是什么关系,好像一直是悬空的,没想过这中间的相关性,证书究竟是怎么起作用的
下面是摘自 cloudflare 的 tls 握手流程,把证书的使用方式说的比较明白了
TLS 握手是由客户端和服务器交换的一系列数据报或消息。TLS 握手涉及多个步骤,因为客户端和服务器要交换完成握手和进行进一步对话所需的信息。
TLS 握手中的确切步骤将根据所使用的密钥交换算法的种类和双方支持的密码套件而有所不同。RSA 密钥交换算法虽然现在被认为不安全,但曾在 1.3 之前的 TLS 版本中使用。大致如下:
为了学习这个过程,我们尝试用 Chrome 的自带抓包工具,以往这是可以通过在 Chrome 地址栏中输入 chrome://net-internals/#events 来打开,现在变成了两部分,chrome://net-export/ 这里可以开始抓包,然后会记录下一个抓包日志文件里,

然后再打开
https://netlog-viewer.appspot.com/#events 来查看具体的日志
这里我们以打开百度为例,即在打开 chrome://net-export/ 并启动抓包后,再在一个新 tab 打开 baidu.com,然后关闭
将日志文件在 https://netlog-viewer.appspot.com/#events 打开

这里可以看到

--> type 1 表示现在 tls 握手进行到哪一步了, 对应的值表示不同的阶段
| 代码(type) | 释义 |
|---|---|
| 0 | HelloRequest |
| 1 | ClientHello |
| 2 | ServerHello |
| 11 | Certificate |
| 12 | ServerKeyExchange |
| 13 | CertificateRequest |
| 14 | ServerHelloDone |
| 15 | CertificateVerify |
| 16 | ClientKeyExchange |
| 20 | Finished |
具体的对应关系是在这边
比如 11 之后表示我们从服务端收到了证书

然后就要去验证证书的可靠性

后面是验证后的结果


最后就是交换对称会话秘钥然后完成握手

sudo docker-compose -f docker-compose-arm64.yml up -dsudo docker-compose up -ddocker-compose.yml==== starting service ==== |
就表示启动成功了,然后就可以访问后面那个地址 http://localhost:8070 进入控制台,默认用户名apollo,密码是admin
然后我们在应用中想要使用,主要是这个几个配置
第一个就是在resources目录下创建apollo-env.properties
里面是meta server的地址,比如我这边就是
dev.meta=http://127.0.0.1:8080 |
这表示是对应的spring.profiles.active是dev的配置
第二步是添加pom依赖
<dependency> |
最后一步是在springboot的启动类添加注解
然后就可以直接使用@Value注解使用配置的值
请求下这个接口,就可以看到对应的值
然后我们可以在控制台修改下这个值,发布
默认日志也会把这个打印出来
2024-08-24 19:38:30.462 INFO 57920 --- [Apollo-Config-1] c.f.a.s.p.AutoUpdateConfigChangeListener : Auto update apollo changed value successfully, new value: apolloDemoValue, key: demo, beanName: demoController, field: com.nicksxs.spbdemo.controller.DemoController.demo |
对应的请求也会拿到最新的值
其实最开始是举重项目,侯志慧是女子 49 公斤级的冠军,这场比赛是全场都看,其实看中国队的举重比赛跟跳水有点像,每一轮都需要到最后才能等到中国队,跳水其实每轮都有,举重会按照自己报的试举重量进行排名,重量大的会在后面举,抓举和挺举各三次试举机会,有时候会看着比较焦虑,一直等不来,怕一上来就没试举成功,而且中国队一般试举重量就是很大的,容易一次试举不成功就马上下一次,连着举其实压力会非常大,说实话真的是外行看热闹,每次都是多懂一点点,这次由于实在是比较无聊,所以看的会比较专心点,对于对应的规则知识点也会多了解一点,同时对于举重,没想到我们国家的这些运动员有这么强,最后八块金牌拿了七块,有一块拿到银牌也是有点因为教练的策略问题,这里其实也稍微知道一点,因为报上去的试举重量是谁小谁先举,并且我们国家都是实力非常强的,所以都会报大一些,并且如果这个项目有实力相近的选手,会比竞对多报一公斤,这样子如果前面竞争对手没举成功,我们把握就很大了,最坏的情况即使对手试举成功了,我们还有机会搏一把,比如谌利军这样的,只是说说感想,举重运动员真的是个比较单纯的群体,而且训练是非常痛苦枯燥的,非常容易受伤,像挺举就有点会压迫呼吸通道,看到好几个都是脸憋得通红,甚至直接因为压迫气道而没法完成后面的挺举,像之前 16 年的举重比赛,有个运动员没成功夺冠就非常愧疚地哭着说对不起祖国,没有获得冠军,这是怎么样的一种歉疚,怎么样的一种纯粹的感情呢,相对应地来说,我又要举男足,男篮的例子了,很多人在那嘲笑我这样对男足男篮愤愤不平的人,说可能我这样的人都没交个税(从缴纳个税的数量比例来算有可能),只是这里有两个打脸的事情,我足额缴纳个税,接近 20%的薪资都缴了个税,并且我买的所有东西都缴了增值税,如果让我这样缴纳了个税,缴纳了增值税的有个人的投票权,我一定会投票不让男足男篮使用我缴纳我的税金,用我们的缴纳的税,打出这么烂的表现,想乒乓球混双,拿个亚军都会被喷,那可是世界第二了,而且是就输了那么一场,足球篮球呢,我觉得是一方面成绩差,因为比赛真的有状态跟心态的影响,偶尔有一场失误非常正常,NBA 被黑八的有这么多强队,但是如果像男足男篮,成绩是越来越差,用范志毅的话来说就是脸都不要了,还有就是精气神,要在比赛中打出胜负欲,保持这种争胜心,才有机会再进步,前火箭队主教练鲁迪·汤姆贾诺维奇的话,“永远不要低估冠军的决心”,即使我现在打不过你,我会在下一次,下下次打败你,竞技体育永远要有这种精神,可以接受一时的失败,但是要保持永远争胜的心。
第一块金牌是杨倩拿下的,中国队拿奥运会首金也是有政治任务的,而恰恰杨倩这个金牌也有点碰巧是对手最后一枪失误了,当然竞技体育,特别是射击,真的是容不得一点点失误,像前面几届的美国神通埃蒙斯,失之毫厘差之千里,但是这个具体评价就比较少,唯一一点让我比较出戏的就是杨倩真的非常像王刚的徒弟漆二娃,哈哈,微博上也有挺多人觉得像,射击还是个比较可以接受年纪稍大的运动员,需要经验和稳定性,相对来说爆发力体力稍好一点,像庞伟这样的,混合团体10米气手枪金牌,36 岁可能其他项目已经是年龄很大了,不过前面说的举重的吕小军军神也是年纪蛮大了,但是非常强,而且在油管上简直就是个神,相对来说射击是关注比较少,杨倩的也只是看了后面拿到冠军这个结果,有些因为时间或者电视上没放,但是成绩还是不错的,没多少喷点。
第二篇先到这,纯主观,轻喷。
]]>还有奥运会像乒乓球,篮球,跳水这几个都是比较喜欢的项目,篮球🏀是从初中开始就也有在自己在玩的,虽然因为身高啊体质基本没什么天赋,但也算是热爱驱动,差不多到了大学因为比较懒才放下了,初中高中还是有很多时间花在上面,不像别人经常打球跑跑跳跳还能长高,我反而一直都没长个子,也因为这个其实蛮遗憾的,后面想想可能是初中的时候远走他乡去住宿读初中,伙食营养跟不上导致的,可能也是自己的一厢情愿吧,总觉得应该还能再长点个,这一点以后我自己的小孩我应该会特别注意这段时间他/她的营养摄入了;然后像乒乓球🏓的话其实小时候是比较讨厌的,因为家里人,父母都没有这类爱好习惯,我也完全不会,但是小学那会班里的“恶霸”就以公平之名要我们男生每个人都排队打几个,我这种不会的反而又要被嘲笑,这个小时候的阴影让我有了比较不好的印象,对它🏓的改观是在工作以后,前司跟一个同样不会的同事经常在饭点会打打,而且那会因为这个其实身体得到了锻炼,感觉是个不错的健身方式,然后又是中国的优势项目,小时候跟着我爸看孔令辉,那时候完全不懂,印象就觉得老瓦很牛,后面其实也没那么关注,上一届好像看了马龙的比赛;跳水也是中国的优势项目,而且也比较简单,不是说真的很简单,就是我们外行观众看着就看看水花大小图一乐。
这次的观赛过程其实主要还是在乒乓球上面,现在都有点怪我的乌鸦嘴,混双我一直就不太放心(关我什么事,我也不专业),然后一直觉得混双是不是不太稳,结果那天看的时候也是因为央视一套跟五套都没放,我家的有线电视又是没有五加体育,然后用电脑投屏就很卡,看得也很不爽,同时那天因为看的时候已经是 2:0还是再后面点了,一方面是不懂每队只有一次暂停,另一方面不知道已经用过暂停了,所以就特别怀疑马林是不是只会无脑鼓掌,感觉作为教练,并且是前冠军,应该也能在擦汗间隙,或者局间休息调整的时候多给些战略战术的指导,类似于后面男团小胖打奥恰洛夫,像解说都看出来了,其实奥恰那会的反手特别顺,打得特别凶,那就不能让他能特别顺手的上反手位,这当然是外行比较粗浅的看法,在混双过程中其实除了这个,还有让人很不爽的就是我们的许昕跟刘诗雯有种拿不出破釜沉舟的勇气的感觉,在气势上完全被对面两位日本乒乓球最讨厌的两位对手压制着,我都要输了,我就每一颗都要不让你好过,因为真的不是说没有实力,对面水谷隼也不是多么多么强的,可能上一届男团许昕输给他还留着阴影,但是以许昕 19 年男单世界第一的实力,目前也排在世界前三,输一场不应该成为这种阻力,有一些失误也很可惜,后面孙颖莎真的打得很解气,第二局一度以为又要被翻盘了,结果来了个大逆转,女团的时候也是,感觉在心态上孙颖莎还是很值得肯定的,少年老成这个词很适合,看其他的视频也觉得莎莎萌萌哒,陈梦总感觉还欠一点王者霸气,王曼昱还是可以的,反手很凶,我觉得其实这一届日本女乒就是打得非常凶,即使像平野这种看着很弱的妹子,打的球可一点都不弱,也是这种凶狠的打法,有点要压制中国的感觉,这方面我觉得是需要改善的,打这种要不就是实力上的完全碾压,要不就是我实力虽然比较没强多少,但是你狠我打得比你还狠,越保守越要输,我不太成熟的想法是这样的,还有就是面对逆境,这个就要说到男队的了,樊振东跟马龙在半决赛的时候,特别是男团的第二盘,樊振东打奥恰很好地表现了这个心态,当然樊振东我不是特别了解,据说他是比较善于打相持,比较善于焦灼的情况,不过整体看下来樊振东还是有一些欠缺,就是面对情况的快速转变应对,这一点也是马龙特别强的,虽然看起来马龙真的是年纪大了点,没有 16 年那会满头发胶,油光锃亮的大背头和满脸胶原蛋白的意气风发,大范围运动能力也弱了一点,但是经验和能力的全面性也让他最终能再次站上巅峰,还是非常佩服的,这里提一下张继科,虽然可能天赋上是张继科更强点,但是男乒一直都是有强者出现,能为国家队付出这么多并且一直坚持的可不是人人都可以,即使现在同台竞技马龙打不过张继科我还是更喜欢马龙。再来说说我们的对手,主要分三部分,德国男乒,里面有波尔(我刚听到的时候在想怎么又出来个叫波尔的,是不是像举重的石智勇一样,又来一个同名的,结果是同一个,已经四十岁了),这真是个让人敬佩的对手,实力强,经验丰富,虽然男单有点可惜,但是帮助男团获得银牌,真的是起到了定海神针的作用;奥恰洛夫,以前完全不认识,或者说看过也忘了,这次是真的有点意外,竟然有这么个马龙护法,其实他也坦言非常想赢一次马龙,并且在半决赛也非常接近赢得比赛,是个实力非常强的对手,就是男团半决赛输给张本智和有点可惜,有点被打蒙的感觉,佛朗西斯卡的话也是实力不错的选手,就是可能被奥恰跟波尔的光芒掩盖了,跟波尔在男团第一盘男双的比赛中打败日本那对男双也是非常给力的,说实话,最后打国乒的时候的确是国乒实力更胜一筹,但是即使德国赢了我也是充满尊敬,拼的就是硬实力,就像第二盘奥恰打樊振东,反手是真的很强,反过来看奥恰可能也不是很善于快速调整,樊振东打出来自己的节奏,主攻奥恰的中路,他好像没什么好办法解决。再来说我最讨厌的日本,嗯,小日本,张本智和、水谷隼、伊藤美诚,一一评价下(我是外行,绝对主观评价),张本智和,父母也是中国人,原来叫张智和,改日本籍后加了个本,被微博网友笑称日本尖叫鸡,男单输给了斯洛文尼亚选手,男团里是赢了两场,但是在我看来其实实力上可能比不上全力的奥恰,主要是特别能叫,会干扰对手,如果觉得这种也是种能力我也无话可说,要是有那种吼声能直接把对手震聋的,都不需要打比赛了,我简单记了下,赢一颗球,他要叫八声,用 LD 的话来说烦都烦死了,心态是在面对一些困境顺境的应对调整适应能力,而不是对这种噪音的适应能力,至少我是这么看的,所以我很期待樊振东能好好地虐虐他,因为其他像林昀儒真的是非常优秀的新选手,所谓的国乒克星估计也是小日本自己说说的,国乒其实有很多对手,马龙跟樊振东在男单半决赛碰到的这两个几乎都差点把他们掀翻了,所以还是练好自己的实力再来吹吧,免得打脸;水谷隼的话真的是长相就是特别地讨厌,还搞出那套不打比赛的姿态,男团里被波尔干掉就是很好的例子,波尔虽然真的很强,但毕竟 40 岁了,跟伊藤美诚一起说了吧,伊藤实力说实话是有的,混双中很大一部分的赢面来自于她,刘诗雯做了手术状态不好,许昕失误稍多,但是这种赢球了就感觉我赢了你一辈子一场没输的感觉,还有那种不知道怎么形容的笑,实力强的正常打比赛的我都佩服,像女团决赛里,平野跟石川佳纯的打法其实也很凶狠,但是都是正常的比赛,即使中国队两位实力不济输了也很正常,这种就真的需要像孙颖莎这样的小魔王无视各种魔法攻击,无视你各种花里胡哨的打法的人好好教训一下,混双输了以后了解了下她,感觉实力真的不错,是个大威胁,但是其实我们孙颖莎也是经历了九个月的继续成长,像张怡宁也评价了她,可能后面就没什么空间了,当然如果由张怡宁来打她就更适合了,净整这些有的没的,就打得你没脾气。
乒乓球的说的有点多,就分篇说了,第一篇先到这。
]]>这个应该是 Dubbo SPI 里最玄妙的东西了,一开始没懂,自适应扩展点加载,dubbo://123.123.123.123:1234/com.nicksxs.demo.service.HelloWorldService?anyhost=true&application=demo&default.loadbalance=random&default.service.filter=LoggerFilter&dubbo=2.5.3&interface=com.nicksxs.demo.service.HelloWorldService&logger=slf4j&methods=method1,method2,method3,method4&pid=4292&retries=0&side=provider&threadpool=fixed&threads=200&timeout=2000×tamp=1590647155886
那我从比较能理解的角度或者说思路去讲讲我的理解,因为直接将原理如果脱离了使用,对于我这样的理解能力比较差的可能会比较吃力,从使用场景开始讲可能会比较舒服了,这里可以看到参数里有蛮多的,举个例子,比如这个 threadpool = fixed,说明线程池使用的是 fixed 对应的实现,也就是下图的这个
这样子似乎没啥问题了,反正就是用dubbo 的 spi 加载嘛,好像没啥问题,其实问题还是存在的,或者说不太优雅,比如要先判断我这个 fixed 对应的实现类是哪个,这里可能就有个 if-else 判断了,但是 dubbo 的开发人员似乎不太想这么做这个事情,
譬如我们在引用一个服务时,在ReferenceConfig 中的
private static final Protocol refprotocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension(); |
就获取了自适应拓展,
public T getAdaptiveExtension() { |
这里也使用了 DCL,来锁cachedAdaptiveInstance,当缓存中没有时就去创建自适应拓展
private T createAdaptiveExtension() { |
生成的代码像这样
package com.alibaba.dubbo.rpc; |

看上面的图,java.sql.Driver就是 spi,对应在classpath 的 META-INF/services 目录下的这个文件,里边的内容就是具体的实现类

简单介绍了 Java的 SPI,再来说说 dubbo 的,dubbo 中为啥要用 SPI 呢,主要是为了框架的可扩展性和性能方面的考虑,比如协议层 dubbo 默认使用 dubbo 协议,同时也支持很多其他协议,也支持用户自己实现协议,那么跟 Java 的 SPI 会有什么区别呢,我们也来看个文件

是不是看着很想,又有点不一样,在 Java 的 SPI 配置文件里每一行只有一个实现类的全限定名,在 Dubbo的 SPI配置文件中是 key=value 的形式,我们只需要对应的 key 就能加载对应的实现,
/** |
这里其实就可以看出来第二个不同点了,就是这个cachedInstances,第一个是不用像 Java 原生的 SPI 那样去遍历加载对应的服务类,只需要通过 key 去寻找,并且寻找的时候会先从缓存的对象里去取,还有就是注意下这里的 DCL(double check lock)
|
然后就是创建扩展了,这里如果 wrapperClasses 就会遍历生成wrapper实例,并做 setter 依赖注入,但是这里cachedWrapperClasses的来源还是有点搞不清楚,得再看下 com.alibaba.dubbo.common.extension.ExtensionLoader#loadFile的具体逻辑
又看了遍新的代码,这个函数被抽出来了
/** |
是否是 wrapperClass 其实就看构造函数的。
]]>Invoker 是 Provider 的一个可调用 Service 的抽象,Invoker 封装了 Provider 地址及 Service 接口信息Directory 代表多个 Invoker,可以把它看成 List<Invoker> ,但与 List 不同的是,它的值可能是动态变化的,比如注册中心推送变更Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker,对上层透明,伪装过程包含了容错逻辑,调用失败后,重试另一个Router 负责从多个 Invoker 中按路由规则选出子集,比如读写分离,应用隔离等LoadBalance 负责从多个 Invoker 中选出具体的一个用于本次调用,选的过程包含了负载均衡算法,调用失败后,需要重选失败自动切换,当出现失败,重试其它服务器 1。通常用于读操作,但重试会带来更长延迟。可通过 retries=”2” 来设置重试次数(不含第一次)。
重试次数配置如下:
<dubbo:service retries=”2” />
这里重点看下 Failover Cluster集群模式的实现
public class FailoverCluster implements Cluster { |
这个代码就非常简单,重点需要看FailoverClusterInvoker里的代码,FailoverClusterInvoker继承了AbstractClusterInvoker类,其中invoke 方法是在抽象类里实现的
|
然后重点就是FailoverClusterInvoker中的doInvoke方法了,其实它里面也就这么一个方法
|
快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks=”2” 来设置最大并行数。
广播调用所有提供者,逐个调用,任意一台报错则报错 2。通常用于通知所有提供者更新缓存或日志等本地资源信息。
]]>synchronized 的一些学习记录
jdk1.6 以后对 synchronized 进行了一些优化,包括偏向锁,轻量级锁,重量级锁等
这些锁的加锁方式大多跟对象头有关,我们可以查看 jdk 代码
首先对象头的位置注释
// Bit-format of an object header (most significant first, big endian layout below): |
enum { locked_value = 0, |
我们可以用 java jol库来查看对象头,通过一段简单的代码来看下
public class ObjectHeaderDemo { |

然后可以看到打印输出,当然这里因为对齐方式,我们看到的其实顺序是反过来的,按最后三位去看,我们这是 001,好像偏向锁都没开,这里使用的是 jdk1.8,默认开始偏向锁的,其实这里有涉及到了一个配置,jdk1.8 中偏向锁会延迟 4 秒开启,可以通过添加启动参数 -XX:+PrintFlagsFinal,看到

因为在初始化的时候防止线程竞争有大量的偏向锁撤销升级,所以会延迟 4s 开启
我们再来延迟 5s 看看
public class ObjectHeaderDemo { |

可以看到偏向锁设置已经开启了,我们来是一下加个偏向锁
public class ObjectHeaderDemo { |
看下运行结果

可以看到是加上了 101 = 5 也就是偏向锁,后面是线程 id
当我再使用一个线程来竞争这个锁的时候
public class ObjectHeaderDemo { |

可以看到变成了轻量级锁,在线程没有争抢,只是进行了切换,就会使用轻量级锁,当两个线程在竞争了,就又会升级成重量级锁
public class ObjectHeaderDemo { |

可以看到变成了重量级锁。
]]>public class SynchronizedDemo { |
然后来查看反编译结果,其实代码(日光)之下并无新事,即使是完全不懂的也可以通过一些词义看出一些意义
Last modified 2021年6月20日; size 729 bytes |
其中lockMethod中可以看到是通过 ACC_SYNCHRONIZED flag 来标记是被 synchronized 修饰,前面的 ACC 应该是 access 的意思,并且通过 ACC_PUBLIC 也可以看出来他们是同一类访问权限关键字来控制的,而修饰类则是通过3: monitorenter和13: monitorexit来控制并发,这个是原来就知道,后来看了下才知道修饰方法是不一样的,但是在前期都比较诟病是 synchronized 的性能,像 monitor 也是通过操作系统的mutex lock互斥锁来实现的,相对是比较重的锁,于是在 JDK 1.6 之后对 synchronized 做了一系列优化,包括偏向锁,轻量级锁,并且包括像 ConcurrentHashMap 这类并发集合都有在使用 synchronized 关键字配合 cas 来做并发保护,
jdk 对于 synchronized 的优化主要在于多重状态锁的升级,最初会使用偏向锁,当一个线程访问同步块并获取锁时,会在对象头和栈帧中的锁记录里存储锁偏向的线程ID,以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁,只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径,因为轻量级锁的获取及释放依赖多次CAS原子指令,而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令(由于一旦出现多线程竞争的情况就必须撤销偏向锁,所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗)。
而当出现线程尝试进入同步块时发现已有偏向锁,并且是其他线程时,会将锁升级成轻量级锁,并且自旋尝试获取锁,如果自旋成功则表示获取轻量级锁成功,否则将会升级成重量级锁进行阻塞,当然这里具体的还很复杂,说的比较浅薄主体还是想将原先的阻塞互斥锁进行轻量化,区分特殊情况进行加锁。
java.lang.Object#equals
public boolean equals(Object obj) { |
对于所有对象的父类,equals 方法其实对比的就是对象的地址,也就是是否是同一个对象,试想如果像 Integer 或者 String 这种,我们没有重写 equals,那其实就等于是在用==,可能就没法达到我们的目的,所以像 String 这种常用的 jdk 类都是默认重写了java.lang.String#equals
public boolean equals(Object anObject) { |
然后呢就是为啥一些书或者 effective java 中写了 equals 跟 hashCode 要一起重写,这里涉及到当对象作为 HashMap 的 key 的时候
首先 HashMap 会使用 hashCode 去判断是否在同一个槽里,然后在通过 equals 去判断是否是同一个 key,是的话就替换,不是的话就链表接下去,如果不重写 hashCode 的话,默认的 object 的hashCode 是 native 方法,根据对象的地址生成的,这样其实对象的值相同的话,因为地址不同,HashMap 也会出现异常,所以需要重写,同时也需要重写 equals 方法,才能确认是同一个 key,而不是落在同一个槽的不同 key.
准备阶段是正式为类中定义的变量(即静态变量,被static修饰的变量)分配内存并设置类变量初始值的阶段
解析阶段是 Java 虚拟机将常量池内的符号引用替换为直接引用的过程
以上验证、准备、解析 三个阶段又合称为链接阶段,链接阶段要做的是将加载到JVM中的二进制字节流的类数据信息合并到JVM的运行时状态中。
类的初始化阶段是类加载过程的最后一个步骤,也是除了自定义类加载器之外将主动权交给了应用程序,其实就是执行类构造器
最终,方法区会存储当前类类信息,包括类的静态变量、类初始化代码(定义静态变量时的赋值语句 和 静态初始化代码块)、实例变量定义、实例初始化代码(定义实例变量时的赋值语句实例代码块和构造方法)和实例方法,还有父类的类信息引用。
]]>类加载机制中说来说去其实也逃不开类加载器这个话题,我们就来说下类加载器这个话题,Java 在 jdk1.2 以后开始有了
Java 虚拟机设计团队有意把加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到 Java 虚拟机外部去实现,以便让应用程序自己去决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”(Class Loader).
其实在 Java 中类加载器有一个很常用的作用,比如一个类的唯一性,其实是由加载它的类加载器和这个类一起来确定这个类在虚拟机的唯一性,这里也参考下周志明书里的例子
public class ClassLoaderTest { |
可以看下结果
这里说明了当一个是由虚拟机的应用程序类加载器所加载的和另一个由自己写的自定义类加载器加载的,虽然是同一个类,但是 instanceof 的结果就是 false 的
自 JDK1.2 以来,Java 一直有些三层类加载器、双亲委派的类加载架构
首先是启动类加载器,Bootstrap Class Loader,这个类加载器负责加载放在
/** |
这个类加载器是在类sun.misc.Launcher.ExtClassLoader中以 Java 代码的形式实现的,它负责在家
这个类加载器是由sun.misc.Launcher.AppClassLoader实现,通过 java 代码,并且是 ClassLoader 类中的 getSystemClassLoader()方法的返回值,可以看一下代码
/** |
它负责加载用户类路径(ClassPath)上所有的类库,我们可以直接在代码中使用这个类加载器,如果我们的代码中没有自定义的类在加载器,一般情况下这个就是程序中默认的类加载器

双亲委派模型的工作过程是:如果一个类加载器收到了类加载的请求,它首先不会自己去尝试家在这个类,而是把这个请求为派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的家在请求最终都应该传送到最顶层的启动类加载器中,只有当父类加载器反馈自己无法完成加载请求(它的搜索范围中没有找到所需要的类)时,子加载器才会尝试自己去完成加载。
使用双亲委派模型来组织类加载器之间的关系,一个显而易见的好处就是 Java 中的类随着它的类加载器一起举杯了一种带有优先级的层次关系。例如类 java.lang.Object,它存放在 rt.jar 之中,无论哪一个类加载器要家在这个类,最终都是委派给处于模型最顶层的启动类加载器进行加载,因此 Object 类在程序的各种类加载器环境中都能够保证是同一个类。反之,如果没有使用双薪委派模型,都由各个类加载器自行去加载的话,如果用户自己也编写了一个名为 java.lang.Object 的类,并放在程序的 ClassPath 中,那系统中就会出现多个不同的 Object 类,Java 类型体系中最基础的行为也就无从保证,应用程序将会变得一片混乱。
可以来看下双亲委派模型的代码实现
/** |
关于破坏双亲委派模型,第一次是在 JDK1.2 之后引入了双亲委派模型之前,那么在那之前已经有了类加载器,所以java.lang.ClassLoader 中添加了一个 protected 方法 findClass(),并引导用户编写的类加载逻辑时尽可能去重写这个方法,而不是在 loadClass()中编写代码。这个跟上面的逻辑其实类似,当父类加载失败,会调用 findClass()来完成加载;第二次是因为这个模型本身还有一些不足之处,比如 SPI 这种,所以有设计了线程下上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过 java.lang.Thread 类的 java.lang.Thread#setContextClassLoader() 进行设置,然后第三种是为了追求程序动态性,这里有涉及到了 osgi 等概念,就不展开了
]]>dump thread 是不现实的,毕竟服务器环境的没法这么操作,那就得用 Java 的那些工具了
譬如 jstack,这个命令其实不能更简单了
看看 help 信息
用-l参数可以打出锁的额外信息,然后后面的 pid 就是进程 id 咯,机智的小伙伴会问了(就你这个小白才问这么蠢的问题🤦♂️),怎么看 Java 应用的进程呢
那就是 jps 了,命令也很简单,一般直接用 jps命令就好了,不过也可以 help 看一下
稍微解释下,-q是只显示进程 id,-m是输出给main 方法的参数,比如我在配置中加给参数
然后用 jps -m查看
-v加上小 v 的话就是打印 jvm 参数
还是有点东西,然后就继续介绍 jstack 了,然后我们看看 jstack 出来是啥,为了加点内容我加了个死锁
public static void main(String[] args) throws InterruptedException { |
然后看看出来时怎么样的
2020-08-02 21:50:32 |
前面的信息其实上次就看过了,后面就可以发现有个死锁了,
上面比较长,把主要的截出来,就是这边的,这点就很强大了。
惯例还是看一下帮助信息
这个相对命令比较多,不过因为现在 dump 下来我们可能会用文件模式,然后将文件下载下来使用 mat 进行分析,所以可以使用jmap -dump:live,format=b,file=heap.bin <pid>
命令照着上面看的就是打印活着的对象,然后以二进制格式,文件名叫 heap.bin 然后最后就是进程 id,打印出来以后可以用 mat 打开
这样就可以很清晰的看到应用里的各种信息,jmap 直接在命令中还可以看很多信息,比如使用jmap -histo <pid>打印对象的实例数和对象占用的内存
jmap -finalizerinfo <pid> 打印正在等候回收的对象
对于一些应用内存已经占满了,jstack 和 jmap 可能会连不上的情况,可以使用-F参数强制打印线程或者 dump 文件,但是要注意这两者使用的用户必须与 java 进程启动用户一致,并且使用的 jdk 也要一致
-H进入线程模式
-H :Threads-mode operation |
这样就能用在 Java 中去 jstack 中找到对应的线程
其实还有比较重要的两个操作,
一个是在 top 启动状态下,按c键,这样能把比如说是一个 Java 进程,具体的进程命令显示出来
像这样
执行前是这样
执行后是这样
第二个就是排序了
SORTING of task window |
查看 man page 可以找到这一段,其实一般 man page 都是最细致的,只不过因为太多了,有时候懒得看,这里可以通过大写 M 和大写 P 分别按内存和 CPU 排序,下面还有两个小技巧,通过按 x 可以将当前活跃的排序列用不同颜色标出来,然后可以通过<和>直接左右移动排序列
首先是org.apache.rocketmq.broker.BrokerStartup中的 main 函数,org.apache.rocketmq.broker.BrokerStartup#createBrokerController基本就是读取参数,这里差点把最核心的初始化给漏了,
final BrokerController controller = new BrokerController( |
前面是以 broker 配置,netty 的服务端和客户端配置,以及消息存储配置在实例化 BrokerController,然后就是初始化了
public boolean initialize() throws CloneNotSupportedException { |
前面这些就是各个配置的 load 了,然后是个我认为比较重要的部分messageStore 的实例化,
if (result) { |
先是实例化,实例化构造函数里的代码比较重要,重点看一下
public DefaultMessageStore(final MessageStoreConfig messageStoreConfig, final BrokerStatsManager brokerStatsManager, |
这里面有很多类,不过先把从构造函数里传进来的忽略下,接下来就是 AllocateMappedFileService 这个service,前面看过文章的可能会根据上面的代码猜到,这也是个 ServiceThread,如果是对RocketMQ 有所了解的可能从名字可以看出这个类是关于 RocketMQ 消息怎么落盘的,当需要创建MappedFile时(在MapedFileQueue.getLastMapedFile方法中),向该线程的requestQueue队列中放入AllocateRequest请求对象,该线程会在后台监听该队列,并在后台创建MapedFile对象,即同时创建了物理文件。然后是创建了 IndexService 服务线程,用来给创建索引;还有是FlushConsumeQueueService是将ConsumeQueue 刷入磁盘;CleanCommitLogService用来清理过期的 CommitLog,默认是 72 小时以上;CleanConsumeQueueService是将小于最新的 CommitLog 偏移量的 ConsumeQueue 清理掉;StoreStatsService是储存统计服务;HAService用于CommitLog 的主备同步;ScheduleMessageService用于定时消息;还有就是这个ReputMessageService非常重要,就是由它实现了将 CommitLog 以 topic+queue 纬度构建 ConsumeQueue,后面TransientStorePool是异步刷盘时的存储buffer,也可以从后面的判断中看出来
public boolean isTransientStorePoolEnable() { |
再然后就是启动两个服务线程,dispatcherList是为CommitLog文件转发请求,差不多这个初始化就这些内容。
然后回到外层,下面是主备切换的配置,然后是数据统计,接着是存储插件加载,然后是往转发器链表里再加一个过滤器
if (messageStoreConfig.isEnableDLegerCommitLog()) { |
接下来就是org.apache.rocketmq.store.MessageStore#load的过程了,
2)调用CommitLog.load方法,在此方法中调用MapedFileQueue.load方法,将$HOME /store/commitlog目录下的所有文件加载到MapedFileQueue的List
3)调用DefaultMessageStore.loadConsumeQueue方法加载consumequeue文件数据到DefaultMessageStore.consumeQueueTable集合中。
初始化StoreCheckPoint对象,加载$HOME/store/checkpoint文件,该文件记录三个字段值,分别是物理队列消息时间戳、逻辑队列消息时间戳、索引队列消息时间戳。
调用IndexService.load方法加载$HOME/store/index目录下的文件。对该目录下的每个文件初始化一个IndexFile对象。然后调用IndexFile对象的load方法将IndexHeader加载到对象的变量中;再根据检查是否存在abort文件,若有存在abort文件,则表示Broker表示上次是异常退出的,则检查checkpoint的indexMsgTimestamp字段值是否小于IndexHeader的endTimestamp值,indexMsgTimestamp值表示最后刷盘的时间,若小于则表示在最后刷盘之后在该文件中还创建了索引,则要删除该Index文件,否则将该IndexFile对象放入indexFileList:ArrayList
然后调用org.apache.rocketmq.store.DefaultMessageStore#recover恢复,前面有根据boolean lastExitOK = !this.isTempFileExist();临时文件是否存在来判断上一次是否正常退出,根据这个状态来选择什么恢复策略
接下去是初始化 Netty 服务端,初始化发送消息线程池(sendMessageExecutor)、拉取消息线程池(pullMessageExecutor)、管理Broker线程池(adminBrokerExecutor)、客户端管理线程池(clientManageExecutor),注册事件处理器,包括发送消息事件处理器(SendMessageProcessor)、拉取消息事件处理器、查询消息事件处理器(QueryMessageProcessor,包括客户端的心跳事件、注销事件、获取消费者列表事件、更新更新和查询消费进度consumerOffset)、客户端管理事件处理器(ClientManageProcessor)、结束事务处理器(EndTransactionProcessor)、默认事件处理器(AdminBrokerProcessor),然后是定时任务
BrokerController.this.getBrokerStats().record(); 记录 Broker 状态
BrokerController.this.consumerOffsetManager.persist(); 持久化consumerOffset
BrokerController.this.consumerFilterManager.persist();持久化consumerFilter
BrokerController.this.protectBroker(); 保护 broker,消费慢,不让继续投递
BrokerController.this.printWaterMark(); 打印水位
log.info("dispatch behind commit log {} bytes", BrokerController.this.getMessageStore().dispatchBehindBytes()); 检查落后程度
BrokerController.this.brokerOuterAPI.fetchNameServerAddr(); 定时获取 nameserver
BrokerController.this.printMasterAndSlaveDiff(); 打印主从不一致
然后是 tsl,初始化事务消息,初始化 RPCHook
请把害怕打到公屏上🤦♂️,从线程池名字和调用的方法应该可以看出大部分的用途
this.remotingServer = new NettyRemotingServer(this.nettyServerConfig, this.clientHousekeepingService); |
Broker 启动过程
贴代码
public void start() throws Exception { |
首先是启动messageStore,调用 start 方法,这里面又调用了一些代码
public void start() throws Exception { |
调用DefaultMessageStore.start方法启动DefaultMessageStore对象中的一些服务线程。
然后是启动ClientHousekeepingService的 netty 服务端和客户端,然后是启动fileWatchService证书服务,接着启动BrokerOuterAPI中的NettyRemotingClient,即建立与NameServer的链接,用于自身Broker与其他模块的RPC功能调用;包括获取NameServer的地址、注册Broker、注销Broker、获取Topic配置、获取消息进度信息、获取订阅关系等RPC功能,然后是PullRequestHoldService服务线程,这个就是实现长轮询的,然后启动管家ClientHousekeepingService服务,负责扫描不活跃的生产者,消费者和 filter,启动FilterServerManager 过滤器服务管理,然后启动定时任务调用org.apache.rocketmq.broker.BrokerController#registerBrokerAll向所有 nameserver 注册 broker,最后是按需开启org.apache.rocketmq.store.stats.BrokerStatsManager和org.apache.rocketmq.broker.latency.BrokerFastFailure,基本上启动过程就完成了
]]>CREATE TABLE `student_time_0` ( |
有这样的三个表,student_time_0, student_time_1, student_time_2, 以 user_id 作为分表键,根据表数量取模作为分表依据
这里先构造点数据,
insert into student_time (`name`, `user_id`, `age`, `create_time`) values (?, ?, ?, ?) |
主要是为了保证 create_time 唯一比较好说明问题,
int i = 0; |
三个表的数据分别是 673,678,650,说明符合预期了,各个表数据不一样,接下来比如我们想要做一个这样的分页查询
select * from student_time ORDER BY create_time ASC limit 1000, 5; |
student_time 对于我们使用的 sharding-jdbc 来说当然是逻辑表,首先从一无所知去想这个查询如果我们自己来处理应该是怎么做,
首先是不是可以每个表都从 333 开始取 5 条数据,类似于下面的查询,然后进行 15 条的合并重排序获取前面的 5 条
select * from student_time_0 ORDER BY create_time ASC limit 333, 5; |
忽略前面 limit 差的 1,这个结果除非三个表的分布是绝对的均匀,否则结果肯定会出现一定的偏差,以为每个表的 333 这个位置对于其他表来说都不一定是一样的,这样对于最后整体的结果,就会出现偏差
因为一直在纠结怎么让这个更直观的表现出来,所以尝试画了个图
黑色的框代表我从每个表里按排序从 334 到 338 的 5 条数据, 他们在每个表里都是代表了各自正确的排序值,但是对于我们想要的其实是合表后的 1001,1005 这五条,然后我们假设总的排序值位于前 1000 的分布是第 0 个表是 320 条,第 1 个表是 340 条,第 2 个表是 340 条,那么可以明显地看出来我这么查的结果简单合并肯定是不对的。
那么 sharding-jdbc 是如何保证这个结果的呢,其实就是我在每个表里都查分页偏移量和分页大小那么多的数据,在我这个例子里就是对于 0,1,2 三个分表每个都查 1005 条数据,即使我的数据不平衡到最极端的情况,前 1005 条数据都出在某个分表中,也可以正确获得最后的结果,但是明显的问题就是大分页,数据较多,就会导致非常大的问题,即使如 sharding-jdbc 对于合并排序的优化做得比较好,也还是需要传输那么大量的数据,并且查询也耗时,那么有没有解决方案呢,应该说有两个,或者说主要是想讲后者
第一个办法是像这种查询,如果业务上不需要进行跳页,而是只给下一页,那么我们就能把前一次的最大偏移量的 create_time 记录下来,下一页就可以拿着这个偏移量进行查询,这个比较简单易懂,就不多说了
第二个办法是看的58 沈剑的一篇文章,尝试理解讲述一下,
这个办法的第一步跟前面那个错误的方法或者说不准确的方法一样,先是将分页偏移量平均后在三个表里进行查询
t0 |
然后要做什么呢,其实目标比较明白,因为前面那种方法其实就是我知道了前一页的偏移量,所以可以直接当做条件来进行查询,那这里我也想着拿到这个条件,所以我将第一遍查出来的最小的 create_time 和最大的 create_time 找出来,然后再去三个表里查询,其实主要是最小值,因为我拿着最小值去查以后我就能知道这个最小值在每个表里处在什么位置,
t0 |
我只贴了前五条数据,为了方便知道偏移量,每个分表都使用了自增主键,我们可以看到前一次查询的最小值分别在其他两个表里的位置分别是 322-1 和 297-1,那么对于总体来说这个时间应该是在 322 - 1 + 333 + 297 - 1 = 951,那这样子我只要对后面的数据最多每个表查 1000 - 951 + 5 = 54 条数据再进行合并排序就可以获得最终正确的结果。
这个就是传说中的二次查询法。
<dependency> |
因为前面有聊过 Spring Boot 的自动加载,在这里 spring 就会自己去找 DataSource 的配置,所以要在入口把它干掉
|
然后因为想在入口跑代码,就实现了下 org.springframework.boot.CommandLineRunner 主要是后面的 Java Config 代码
|
然后我们就可以在使用这个 DataSource 了,先看下这两个表的数据

|
看下查询结果
ResultSet resultSet = ps.executeQuery(sql); |
实际上应该是
ResultSet resultSet = ps.executeQuery(); |
而这里的差别就是,是否传 sql 这个参数,首先我们要知道这个 ps 是什么,它也是个接口java.sql.PreparedStatement,而真正的实现类是org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement,我们来看下继承关系
这里可以看到继承关系里有org.apache.shardingsphere.driver.jdbc.unsupported.AbstractUnsupportedOperationPreparedStatement
那么在我上面的写错的代码里
|
这个报错一开始让我有点懵,后来点进去了发现是这么个异常,但是我其实一开始是用的更新语句,以为更新不支持,因为平时使用没有深究过,以为是不是需要使用 Mybatis 才可以执行更新,但是理论上也不应该,再往上看原来这些异常是由 sharding-jdbc 包装的,也就是在上面说的AbstractUnsupportedOperationPreparedStatement,这其实也是一种设计思想,本身 jdbc 提供了一系列接口,由各家去支持,包括 mysql,sql server,oracle 等,而正因为这个设计,所以 sharding-jdbc 也可以在此基础上进行设计,我们可以总体地看下 sharding-jdbc 的实现基础
看了前面ShardingSpherePreparedStatement的继承关系,应该也能猜到这里的几个类都是实现了 jdbc 的基础接口,
在前一篇的 demo 中的
Connection conn = dataSource.getConnection(); |
其实就获得了org.apache.shardingsphere.driver.jdbc.core.connection.ShardingSphereConnection#ShardingSphereConnection
然后获得java.sql.PreparedStatement
PreparedStatement ps = conn.prepareStatement(sql) |
就是获取了org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement
然后就是执行
ResultSet resultSet = ps.executeQuery(); |
然后获得结果org.apache.shardingsphere.driver.jdbc.core.resultset.ShardingSphereResultSet
其实像 mybatis 也是基于这样去实现的
]]>public Executor getExecutor(URL url) { |
public Executor getExecutor(URL url) { |
public Executor getExecutor(URL url) { |
public Executor getExecutor(URL url) { |
/** |
m_low_limit_id赋的值是trx_sys->max_trx_id,代表的是当前系统最小的未分配的事务 id,所以呢,举个例子,当前有三个活跃事务,事务 id 分别是 100,200,300,而 m_up_limit_id = 100, m_low_limit_id = 301,当事务 id 是 200 的提交之后,它的更新就是可以被 100 和 300 看到,而不是说 m_ids 里没了 200,并且 200 比 100 大就应该不可见了
还有一个问题是幻读的问题,这貌似也是个高频面试题,啥意思呢,或者说跟它最常拿来比较的脏读,脏读是指读到了别的事务未提交的数据,因为未提交,严格意义上来讲,不一定是会被最后落到库里,可能会回滚,也就是在 read uncommitted 级别下会出现的问题,但是幻读不太一样,幻读是指两次查询的结果数量不一样,比如我查了第一次是 select * from table1 where id < 10 for update,查出来了一条结果 id 是 5,然后再查一下发现出来了一条 id 是 5,一条 id 是 7,那是不是有点尴尬了,其实呢这个点我觉得脏读跟幻读也比较是从原理层面来命名,如果第一次接触的同学发觉有点不理解也比较正常,因为从逻辑上讲总之都是数据不符合预期,但是基于源码层面其实是不同的情况,幻读是在原先的 read view 无法完全解决的,怎么解决呢,简单的来说就是锁咯,我们知道innodb 是基于 record lock 行锁的,但是貌似没有办法解决这种问题,那么 innodb 就引入了 gap lock 间隙锁,比如上面说的情况下,id 小于 10 的情况下,是都应该锁住的,gap lock 其实是基于索引结构来锁的,因为索引树除了树形结构之外,还有一个next record 的指针,gap lock 也是基于这个来锁的
看一下 mysql 的文档
SELECT … FOR UPDATE sets an exclusive next-key lock on every record the search encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
对于一个 for update 查询,在 RR 级别下,会设置一个 next-key lock在每一条被查询到的记录上,next-lock 又是啥呢,其实就是 gap 锁和 record 锁的结合体,比如我在数据库里有 id 是 1,3,5,7,10,对于上面那条查询,查出来的结果就是 1,3,5,7,那么按照文档里描述的,对于这几条记录都会加上next-key lock,也就是(-∞, 1], (1, 3], (3, 5], (5, 7], (7, 10) 这些区间和记录会被锁起来,不让插入,再唠叨一下呢,就是其实如果是只读的事务,光 read view 一致性读就够了,如果是有写操作的呢,就需要锁了。
]]>select * from table1 where id = 1这种查询语句其实是不会加传说中的锁的,当然这里是指在 RR 或者 RC 隔离级别下,
SELECT ... FROMis a consistent read, reading a snapshot of the database and setting no locks unless the transaction isolation level is set to SERIALIZABLE. For SERIALIZABLE level, the search sets shared next-key locks on the index records it encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
纯粹的这种一致性读,实际读取的是快照,也就是基于 read view 的读取方式,除非当前隔离级别是SERIALIZABLE
但是对于以下几类
select * from table where ? lock in share mode;select * from table where ? for update;insert into table values (...);update table set ? where ?;delete from table where ?;除了第一条是 S 锁之外,其他都是 X 排他锁,这边在顺带下,S 锁表示共享锁, X 表示独占锁,同为 S 锁之间不冲突,S 与 X,X 与 S,X 与 X 之间都冲突,也就是加了前者,后者就加不上了
我们知道对于 RC 级别会出现幻读现象,对于 RR 级别不会出现,主要的区别是 RR 级别下对于以上的加锁读取都根据情况加上了 gap 锁,那么是不是 RR 级别下以上所有的都是要加 gap 锁呢,当然不是
举个例子,RR 事务隔离级别下,table1 有个主键id 字段select * from table1 where id = 10 for update
这条语句要加 gap 锁吗?
答案是不需要,这里其实算是我看了这么久的一点自己的理解,啥时候要加 gap 锁,判断的条件是根据我查询的数据是否会因为不加 gap 锁而出现数量的不一致,我上面这条查询语句,在什么情况下会出现查询结果数量不一致呢,只要在这条记录被更新或者删除的时候,有没有可能我第一次查出来一条,第二次变成两条了呢,不可能,因为是主键索引。
再变更下这个题的条件,当 id 不是主键,但是是唯一索引,这样需要怎么加锁,注意问题是怎么加锁,不是需不需要加 gap 锁,这里呢就是稍微延伸一下,把聚簇索引(主键索引)和二级索引带一下,当 id 不是主键,说明是个二级索引,但是它是唯一索引,体会下,首先对于 id = 10这个二级索引肯定要加锁,要不要锁 gap 呢,不用,因为是唯一索引,id = 10 只可能有这一条记录,然后呢,这样是不是就好了,还不行,因为啥,因为它是二级索引,对应的主键索引的记录才是真正的数据,万一被更新掉了咋办,所以在 id = 10 对应的主键索引上也需要加上锁(默认都是 record lock行锁),那主键索引上要不要加 gap 呢,也不用,也是精确定位到这一条记录
最后呢,当 id 不是主键,也不是唯一索引,只是个普通的索引,这里就需要大名鼎鼎的 gap 锁了,
是时候画个图了
其实核心的目的还是不让这个 id=10 的记录不会出现幻读,那么就需要在 id 这个索引上加上三个 gap 锁,主键索引上就不用了,在 id 索引上已经控制住了id = 10 不会出现幻读,主键索引上这两条对应的记录已经锁了,所以就这样 OK 了
其中 innodb 的事务隔离用到了标题里说到的 mvcc,Multiversion concurrency control, 直译过来就是多版本并发控制,先不讲这个究竟是个啥,考虑下如果纯猜测,这个事务隔离级别应该会是怎么样实现呢,愚钝的我想了下,可以在事务开始的时候拷贝一个表,这个可以支持 RR 级别,RC 级别就不支持了,而且要是个非常大的表,想想就不可行
腆着脸说虽然这个不可行,但是思路是对的,具体实行起来需要做一系列(肥肠多)的改动,首先根据我的理解,其实这个拷贝一个表是变成拷贝一条记录,但是如果有多个事务,那就得拷贝多次,这个问题其实可以借助版本管理系统来解释,在用版本管理系统,git 之类的之前,很原始的可能是开发完一个功能后,就打个压缩包用时间等信息命名,然后如果后面要找回这个就直接用这个压缩包的就行了,后来有了 svn,git 中心式和分布式的版本管理系统,它的一个特点是粒度可以控制到文件和代码行级别,对应的我们的 mysql 事务是不是也可以从一开始预想的表级别细化到行的级别,可能之前很多人都了解过,数据库的一行记录除了我们用户自定义的字段,还有一些额外的字段,去源码data0type.h里捞一下
/* Precise data types for system columns and the length of those columns; |
一个是 DATA_ROW_ID,这个是在数据没指定主键的时候会生成一个隐藏的,如果用户有指定主键就是主键了
一个是 DATA_TRX_ID,这个表示这条记录的事务 ID
还有一个是 DATA_ROLL_PTR 指向回滚段的指针
指向的回滚段其实就是我们常说的 undo log,这里面的具体结构就是个链表,在 mvcc 里会使用到这个,还有就是这个 DATA_TRX_ID,每条记录都记录了这个事务 ID,表示的是这条记录的当前值是被哪个事务修改的,下面就扯回事务了,我们知道 Read Uncommitted, 其实用不到隔离,直接读取当前值就好了,到了 Read Committed 级别,我们要让事务读取到提交过的值,mysql 使用了一个叫 read view 的玩意,它里面有这些值是我们需要注意的,
m_low_limit_id, 这个是 read view 创建时最大的活跃事务 id
m_up_limit_id, 这个是 read view 创建时最小的活跃事务 id
m_ids, 这个是 read view 创建时所有的活跃事务 id 数组
m_creator_trx_id 这个是当前记录的创建事务 id
判断事务的可见性主要的逻辑是这样,
id 小于最小活跃事务 id,说明是可见的,id 等于当前事务 id,说明是自己的更改,可见id 大于最大的活跃事务 id, 不可见id 介于 m_low_limit_id 和 m_up_limit_id 之间,则要判断它是否在 m_ids 中,如果在,不可见,如果不在,表示已提交,可见/** Check whether the changes by id are visible. |
Read Committed 和 Repeated Read 也不一样,那前面说的 read view 都能支持吗,又是怎么支持呢,假如这个 read view 是在事务一开始就创建,那好像能支持的只是 RR 事务隔离级别,其实呢,这是通过创建 read view的时机,对于 RR 级别,就是在事务的第一个 select 语句是创建,对于 RC 级别,是在每个 select 语句执行前都是创建一次,那样就可以保证能读到所有已提交的数据CREATE TABLE `null_index_t` ( |
用个存储过程来插入数据
|
然后看下我们的 is null 查询
EXPLAIN select * from null_index_t WHERE null_key is null; |

再来看看另一个
EXPLAIN select * from null_index_t WHERE null_key is not null; |

从这里能看出来啥呢,可以思考下
从上面可以发现,is null应该是用上了索引了,所以至少不是一刀切不能用,但是看着is not null好像不太行额
我们在做一点小改动,把这个表里的数据改成 9100 条是 null,剩下 900 条是有值的,然后再执行下
然后再来看看执行结果
EXPLAIN select * from null_index_t WHERE null_key is null; |

EXPLAIN select * from null_index_t WHERE null_key is not null; |

是不是不一样了,这里再补充下我试验使用的 mysql 是 5.7 的,不保证在其他版本的一致性,
其实可以看出随着数据量的变化,mysql 会不会使用索引是会变化的,不是说 is not null 一定会使用,也不是一定不会使用,而是优化器会根据查询成本做个预判,这个预判尽可能会减小查询成本,主要包括回表啥的,但是也不一定完全准确。
缓存穿透是指当数据库中本身就不存在这个数据的时候,使用一般的缓存策略时访问不到缓存后就访问数据库,但是因为数据库也没数据,所以如果不做任何策略优化的话,这类数据就每次都会访问一次数据库,对数据库压力也会比较大。
缓存击穿跟穿透比较类似的,都是访问缓存不在,然后去访问数据库,与穿透不一样的是击穿是在数据库中存在数据,但是可能由于第一次访问,或者缓存过期了,需要访问到数据库,这对于访问量小的情况其实算是个正常情况,但是随着请求量变高就会引发一些性能隐患。
缓存雪崩就是击穿的大规模集群效应,当大量的缓存过期失效的时候,这些请求都是直接访问到数据库了,会对数据库造成很大的压力。
对于以上三种场景也有一些比较常见的解决方案,但也不能说是万无一失的,需要随着业务去寻找合适的方案
对于数据库中就没这个数据的时候,一种是可以对这个 key 设置下空值,即以一个特定的表示是数据库不存在的,这种情况需要合理地调整过期时间,当这个 key 在数据库中有数据了的话,也需要有策略去更新这个值,并且如果这类 key 非常多,这个方法就会不太合适,就可以使用第二种方法,就是布隆过滤器,bloom filter,前置一个布隆过滤器,当这个 key 在数据库不存在的话,先用布隆过滤器挡一道,如果不在的话就直接返回了,当然布隆过滤器不是绝对的准确的
当一个 key 的缓存过期了,如果大量请求过来访问这个 key,请求都会落在数据库里,这个时候就可以使用一些类似于互斥锁的方式去让一个线程去访问数据库,更新缓存,但是这里其实也有个问题,就是如果是热点 key 其实这种方式也比较危险,万一更新失败,或者更新操作的时候耗时比较久,就会有一大堆请求卡在那,这种情况可能需要有一些异步提前刷新缓存,可以结合具体场景选择方式
雪崩的情况是指大批量的 key 都一起过期了,击穿的放大版,大批量的请求都打到数据库上了,一方面有可能直接缓存不可用了,就需要用集群化高可用的缓存服务,然后对于实际使用中也可以使用本地缓存结合 redis 缓存,去提高可用性,再配合一些限流措施,然后就是缓存使用过程总的过期时间最好能加一些随机值,防止在同一时间过期而导致雪崩,结合互斥锁防止大量请求打到数据库。
]]>Spring Boot应用,在这个应用范围内,我的常规 bean 是单例的,意味着 getBean 的时候其实永远只会拿到那一个对象,那要怎么来写一个单例呢,首先就是传说中的饿汉模式,也是最简单的
public class Singleton1 { |
上面借鉴了一些代码,其实这是最基本,也不会错的方法,但是正如其中getDate方法里说的问题,有时候并没有想那这个对象,但是因为我调用了这个类的静态方法,导致对象已经生成了,可能这也是饿汉模式名字的来由,不管三七二十一给你生成个单例就完事了,不管有没有用,但是这种个人觉得也没啥大问题,如果是面试的话最好说出来它的缺点
public class Singleton2 { |
这里容易错的有三点,理解了其实就比较好记了
第一点,为啥不在 getInstance 上整个代码块加 synchronized,这个其实比较容易理解,就是锁的力度太大,性能太差了,这点其实也要去理解,可以举个夸张的例子,比如我一个电商的服务,如果为了避免一个人的订单出现问题,是不是可以从请求入口就把他锁住,到请求结束释放,那么里面做的事情都有保障,然而这显然不可能,因为我们想要这种竞态条件抢占资源的时间尽量减少,防止其他线程等待。
第二点,为啥synchronized之已经检查了 instance == null,还要在里面再检查一次,这个有个术语,叫 double check lock,但是为啥要这么做呢,其实很简单,想象当有两个线程,都过了第一步为空判断,这个时候只有一个线程能拿到这个锁,另一个线程就等待了,如果不再判断一次,那么第一个线程新建完对象释放锁之后,第二个线程又能拿到锁,再去创建一个对象。
第三点,为啥要volatile关键字,原先对它的理解是它修饰的变量在 JMM 中能及时将变量值写到主存中,但是它还有个很重要的作用,就是防止指令重排序,instance = new Singleton();这行代码其实在底层是分成三条指令执行的,第一条是在堆上申请了一块内存放这个对象,但是对象的字段啥的都还是默认值,第二条是设置对象的值,比如上面的 m 是 9,然后第三条是将这个对象和虚拟机栈上的指针建立引用关联,那么如果我不用volatile关键字,这三条指令就有可能出现重排,比如变成了 1-3-2 这种顺序,当执行完第二步时,有个线程来访问这个对象了,先判断是不是空,发现不是空的,就拿去直接用了,是不是就出现问题了,所以这个volatile也是不可缺少的
public class Singleton3 { |
这个我个人感觉是饿汉模式的升级版,可以在调用getInstance的时候去实例化对象,也是比较推荐的
public enum Singleton { |
枚举很特殊,它在类加载的时候会初始化里面的所有的实例,而且 JVM 保证了它们不会再被实例化,所以它天生就是单例的。
]]>springboot 相比 spring能更方便开发人员上手,比较重要的一点就是自动装配,大致来看下这个逻辑
public static void main(String[] args) { |
然后就是上面调用的 run 方法
public static ConfigurableApplicationContext run(Class<?> primarySource, String... args) { |
继续往下看
public static ConfigurableApplicationContext run(Class<?>[] primarySources, String[] args) { |
调用SpringApplication的构造方法
/** |
这里就是重点了
private List<BootstrapRegistryInitializer> getBootstrapRegistryInitializersFromSpringFactories() { |
|
我们可以看下 spring-boot-autoconfigure 的 META-INF/spring.factories
# Initializers |
上面根据 org.springframework.boot.autoconfigure.EnableAutoConfiguration 获取的各个配置类,在通过反射加载就能得到一堆 JavaConfig配置类,然后再根据 ConditionalOnProperty等条件配置加载具体的 bean,大致就是这么个逻辑
]]>icu4c 这个库的更新导致的,比如最近我又碰到了$(brew --prefix)/Homebrew/Library/Taps/homebrew/homebrew-core/Formula$(brew --prefix) 还是有效的,不过路径变更为了 /opt/homebrew,但是后面的路径改变了,变成了 /Library/Taps/homebrew/homebrew-core/FormulaHomebrew , 这是第一点,icu4c.rb 的重新安装e3317b86c11c644e88c762e03eb7b310c3337587 这个 commit id 这样,
git checkout -b icu4c-71 e3317b86c11c644e88c762e03eb7b310c3337587 |
但是由于目前的brew已经没有 switch 命令了,所以只能把最新版本的卸载掉,再进行安装老版本
先通过
brew uninstall icu4c |
卸载老版本的 icu4c
然后再使用
brew reinstall ./icu4c.rb |
安装 71 版本的,这样就能解决这个问题
第三个问题会在安装时出现
类似于
attestation verification failed: Failure while executing; `/usr/bin/env GH_TOKEN=****** /usr/local/bin/gh attestation verify /Users/xxx/Library/Caches/Homebrew/downloads/ |
这样的操作,可以通过设置常量的形式来解决
export HOMEBREW_NO_VERIFY_ATTESTATIONS=true |
这样就不去做这个验证了
]]>dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.64.dylib |
这是什么鬼啊,然后我去这个目录下看了下,已经都是libicui18n.67.dylib了,而且它没有把原来的版本保留下来,首先这个是个叫 icu4c是啥玩意,谷歌了一下
ICU4C是ICU在C/C++平台下的版本, ICU(International Component for Unicode)是基于”IBM公共许可证”的,与开源组织合作研究的, 用于支持软件国际化的开源项目。ICU4C提供了C/C++平台强大的国际化开发能力,软件开发者几乎可以使用ICU4C解决任何国际化的问题,根据各地的风俗和语言习惯,实现对数字、货币、时间、日期、和消息的格式化、解析,对字符串进行大小写转换、整理、搜索和排序等功能,必须一提的是,ICU4C提供了强大的BIDI算法,对阿拉伯语等BIDI语言提供了完善的支持。
然后首先想到的解决方案就是能不能我使用brew install icu4c@64来重装下原来的版本,发现不行,并木有,之前的做法就只能是去网上把 64 的下载下来,然后放到这个目录,比较麻烦不智能,虽然没抱着希望在谷歌着,不过这次竟然给我找到了一个我认为非常 nice 的解决方案,因为是在 Stack Overflow 找到的,本着写给像我这样的小小白看的,那就稍微翻译一下
第一步,我们到 brew的目录下
cd $(brew --prefix)/Homebrew/Library/Taps/homebrew/homebrew-core/Formula |
这个可以理解为是 maven 的 pom 文件,不过有很多不同之处,使用ruby 写的,然后一个文件对应一个组件或者软件,那我们看下有个叫icu4c.rb的文件,
第二步看看它的提交历史
git log --follow icu4c.rb |
在 git log 的海洋中寻找,寻找它的(64版本)的身影
第三步注意这三个红框,Stack Overflow 给出来的答案这一步是找到这个 commit id 直接切出一个新分支
git checkout -b icu4c-63 e7f0f10dc63b1dc1061d475f1a61d01b70ef2cb7 |
其实注意 commit id 旁边的红框,这个是有tag 的,可以直接
git checkout icu4c-64 |
PS: 因为我的问题是出在 64 的问题,Stack Overflow 回答的是 63 的,反正是一样的解决方法
第四部,切回去之后我们就可以用 brew 提供的基于文件的安装命令来重新装上 64 版本
brew reinstall ./icu4c.rb |
然后就是第五步,切换版本
brew switch icu4c 64.2 |
最后把分支切回来
git checkout master |
是不是感觉很厉害的解决方法,大佬还提供了一个更牛的,直接写个 zsh 方法
zsh |
对应自己的版本改改版本号就可以了,非常好用。
]]>比如我们在代码中 new 一个 ThreadLocal,
public static void main(String[] args) { |
这里构造了两个线程,一个先往里设值,一个后从里取,运行看下结果,
知道这个用法的话肯定知道是取不到值的,只是具体的原理原来搞错了,我们来看下设值 set 方法
public void set(T value) { |
写博客这会我才明白我原来咋会错得这么离谱,看到第一行代码 t 就是当前线程,然后第二行就是用这个线程去getMap,然后我是把这个当成从 map 里取值了,其实这里是
ThreadLocalMap getMap(Thread t) { |
获取 t 的 threadLocals 成员变量,那这个 threadLocals 又是啥呢
它其实是线程 Thread 中的一个类型是java.lang.ThreadLocal.ThreadLocalMap的成员变量
这是 ThreadLocal 的一个静态成员变量
static class ThreadLocalMap { |
全部代码有点长,只截取了一小部分,然后我们再回头来分析前面说的 set 过程,再 copy 下代码
public void set(T value) { |
获取到 map 以后呢,如果 map 不为空,就往 map 里 set,这里注意 key 是啥,其实是当前这个 ThreadLocal,这里就比较明白了究竟是啥结构,每个线程都会维护自身的 ThreadLocalMap,它是线程的一个成员变量,当创建 ThreadLocal 的时候,进行设值的时候其实是往这个 map 里以 ThreadLocal 作为 key,往里设 value。
这里又要看下前面的 ThreadLocalMap 结构了,类似 HashMap,它有个 Entry 结构,在设置的时候会先包装成一个 Entry
private void set(ThreadLocal<?> key, Object value) { |
这里其实比较重要的就是前面的 Entry 的构造方法,Entry 是个 WeakReference 的子类,然后在构造方法里可以看到 key 会被包装成一个弱引用,这里为什么使用弱引用,其实是方便这个 key 被回收,如果前面的 ThreadLocal tl实例被设置成 null 了,如果这里是直接的强引用的话,就只能等到线程整个回收了,但是其实是弱引用也会有问题,主要是因为这个 value,如果在 ThreadLocal tl 被设置成 null 了,那么其实这个 value 就会没法被访问到,所以最好的操作还是在使用完了就 remove 掉
]]>这里看上去是有点民国时期的建筑风格,部分像那种电视里的租界啥的,不过这次去的时候都在翻修,路一大半拦起来了,听导游说这里往里面走有个局口街,然后上次听前同事说厦门比较有名的就是沙茶面和海蛎煎,不出意料的不太爱吃,沙茶面比较普通,可能是没吃到正宗的,海蛎煎吃不惯,倒是有个大叔的沙茶里脊还不错,在局口街那,还有小哥在那拍,应该也算是个网红打卡点了,然后吃了个油条麻糍也还不错,总体如果是看建筑的话可能最近不是个好时间,个人也没这方面爱好,吃的话最好多打听打听沙茶面跟海蛎煎哪里正宗。如果不知道哪家好吃,也不爱看这类建筑的可以排个坑。
鼓浪屿也是完全没啥概念,需要乘船过去,但是只要二十分钟,岛上没有机动车,基本都靠走,有几个比较有名的地方,菽庄花园,里面有钢琴博物馆,对这个感兴趣的可以去看看,旁边是沙滩还可以逛逛,然后有各种博物馆,风琴啥的,岛上最大的特色是巷子多,道听途说有三百多条小巷,还有几个网红打卡点,周杰伦晴天墙,还有个最美转角,都是挤满了人排队打卡拍照,不过如果不着急,慢慢悠悠逛逛还是不错的,比较推荐,推荐值☆☆
一直读不对这个字,都是叫:那个曾什么垵,愧对语文老师,这里到算是意外之喜,鼓浪屿回来已经挺累了,不过由于比较饿(什么原因后面说),并且离住的地方不远,就过去逛了逛,东西还蛮好吃的,芒果挺便宜,一大杯才十块,无骨鸡爪很贵,不是特别爱,臭豆腐不错的,也不算很贵,这里想起来,那边八婆婆的豆乳烧仙草还不错的,去中山路那会喝了,来曾厝垵也买了,奶茶爱好者可以试试,含糖量应该很高,不爱甜食或者减肥的同学慎重考虑好了再尝试,晚上那边从牌坊出来,沿着环岛路挺多夜宵店什么的,非常推荐,推荐值☆☆☆☆
植物园还是挺名副其实的,有热带植物,沙漠多肉,因为赶时间逛得不多,热带雨林植物那太多人了,都是在那拍照,而且我指的拍照都是拍人照,本身就很小的路,各种十八线网红,或者普通游客在那摆 pose 拍照,挺无语的;沙漠多肉比较惊喜,好多比人高的仙人掌,一大片的仙人球,很可恶的是好多大仙人掌上都有人刻字,越来越体会到,我们社会人多了,什么样的都有,而且不少;还看了下百花厅,但没什么特别的,可能赶时间比较着急,没仔细看,比较推荐,推荐值☆☆☆
对这个其实比较排斥,主要是比较晚了,跑的有点远(我太懒了),一开始真的挺拉低体验感受的,上来个什么书法家,现场画马,卖画;不过后面的还算值回票价,主题是花木兰,空中动作应该很考验基本功,然后那些老外的飞轮还跳绳(不知道学名叫啥),动物那块不太忍心看,应该是吃了不少苦头,不过人都这样就往后点再心疼动物吧。
厦门是个非常适合干饭人的地方,吃饭的地方大部分是差不多一桌菜十个左右就完了,而且上来就一大碗饭,一瓶雪碧一瓶可乐,对于经常是家里跟亲戚吃饭都得十几二十个菜的乡下人来说,不太吃得惯这样的🤦♂️,当然很有可能是我们预算不足,点的差。但是有一点是我回杭州深有感触的,感觉杭州司机的素质真的是跟厦门的司机差了比较多,杭州除非公交车停了,否则人行道很难看到主动让人的,当然这里拿厦门这个旅游城市来对比也不是很公平,不过这也是体现城市现代化文明水平的一个维度吧。
]]>
|
functionalInterface本质还是个接口,所以可以用类实现接口的方式
比如像这样
public class FunctionalInterfaceImpl implements FunctionalInterfaceTest{ |
但是有下面另外两种方式也是可以实现接口的
第一种是 lambda,
FunctionalInterfaceTest interfaceTest = () -> "aaa"; |
这个实现方式就是直接把 lambda 表达式作为接口实现,但是如果这样就要注意如果实在代码中间的话,debug 还是会跳到这个 lambda 的实现,有时候会混乱,因为只是跳转到 lambda 表达式,而不是所在的方法
第二种是这样
public static void main(String[] args) { |
前面 getSelfInfo 的返回值就是类里的一个方法,可以用来作为 FunctionalInterface 的实现,这里跟上面有个比较奇怪的,或者说对于常规的接口理解,一般来说实现的方法签名必须和接口的方法签名一致,但是对于函数接口,私域就突破了这个限制,不管是lambda 这种匿名函数或者后面这种方法引用,都没有用 getInfo 这个方法名,这也是一个比较最近的一个理解。
"main@1" prio=5 tid=0x1 nid=NA runnable |
这就是我们主线程的堆栈信息了,main 表示这个线程名,prio表示优先级,默认是 5,tid 表示线程 id,nid 表示对应的系统线程,后面的runnable 表示目前线程状态,因为是被我打了断点,所以是就许状态,然后下面就是对应的线程栈内容了,在TreeDistance类的 treeDist方法中,对应的文件行数是 64 行。
这里使用 thread dump一般也不会是上面我截图代码里的这种代码量很少的,一般是大型项目,有时候跑着跑着没反应,又不知道跑到哪了,特别是一些刚接触的大项目或者需要定位一个大项目的一个疑难问题,一时没思路时,可以使用这个方法,个人觉得非常有帮助。
ACID,是指数据库管理系统(DBMS)在写入或更新资料的过程中,为保证事务(transaction)是正确可靠的,所必须具备的四个特性:原子性(atomicity,或称不可分割性)、一致性(consistency)、隔离性(isolation,又称独立性)、持久性(durability)。
Atomicity(原子性):一个事务(transaction)中的所有操作,或者全部完成,或者全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。即,事务不可分割、不可约简。[1]
Consistency(一致性):在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。[1]
Isolation(隔离性):数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括未提交读(Read uncommitted)、提交读(read committed)、可重复读(repeatable read)和串行化(Serializable)。[1]
Durability(持久性):事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。[1]
在mysql中,借助于MVCC,各种级别的锁,日志等特性来实现了事务的ACID,但是这个我们通常是对于一个数据库服务的定义,常见的情况下我们的数据库随着业务发展也会从单实例变成多实例,组成主从Master-Slave架构,这个时候其实会有一些问题随之出现,比如说主从同步延迟,假如在业务代码中做了读写分离,对于一些敏感度较低的数据其实问题不是很大,只要主从延迟不到特别夸张的地步一般都是可以忍受的,但是对于一些核心的业务数据,比如订单之类的,不能忍受数据不一致,下了单了,付了款了,一刷订单列表,发现这个订单还没支付,甚至订单都没在,这对于用户来讲是恨不能容忍的错误,那么这里就需要一些措施,要不就不读写分离,要不就在 redis 这类缓存下订单,或者支付后加个延时等,这些都是一些补偿措施,并且这也是一个不太切当的例子,比较合适的例子也可以用这个下单来说,一般在电商平台下单会有挺多要做的事情,比如像下面这个图

下单的是后要冻结核销优惠券,如果账户里有钱要冻结扣除账户里的钱,如果使用了J 豆也一样,可能还有 E 卡,忽略我借用的平台,因为目前一般后台服务化之后,可能每一项都是对应的一个后台服务,我们期望的执行过程是要不全成功,要不就全保持执行前状态,不能是部分扣减核销成功了,部分还不行,所以我们处理这种情况会引入一些通用的方案,第一种叫二阶段提交,
二阶段提交(英语:Two-phase Commit)是指在计算机网络以及数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常,二阶段提交也被称为是一种协议(Protocol)。在分布式系统中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此,二阶段提交的算法思路可以概括为: 参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
对于上面的例子,我们将整个过程分成两个阶段,首先是提交请求阶段,这个阶段大概需要做的是确定资源存在,锁定资源,可能还要做好失败后回滚的准备,如果这些都 ok 了那么就响应成功,这里其实用到了一个叫事务的协调者的角色,类似于裁判员,每个节点都反馈第一阶段成功后,开始执行第二阶段,也就是实际执行操作,这里也是需要所有节点都反馈成功后才是执行成功,要不就是失败回滚。其实常用的分布式事务的解决方案主要也是基于此方案的改进,比如后面介绍的三阶段提交,有三阶段提交就是因为二阶段提交比较尴尬的几个点,
所以三阶段提交引入了各节点的超时机制和一个准备阶段,首先是一个can commit阶段,询问下各个节点有没有资源,能不能进行操作,这个阶段不阻塞,只是提前做个摸底,这个阶段其实人畜无害,但是能提高成功率,在这个阶段如果就有节点反馈是不接受的,那就不用执行下去了,也没有锁资源,然后第二阶段是 pre commit ,这个阶段做的事情跟原来的 第一阶段比较类似,然后是第三阶段do commit,其实三阶段提交我个人觉得只是加了个超时,和准备阶段,好像木有根本性的解决的两阶段提交的问题,后续可以再看看一些论文来思考讨论下。
2020年05月24日22:11 更新
这里跟朋友讨论了下,好像想通了最核心的一点,对于前面说的那个场景,如果是两阶段提交,如果各个节点中有一个没回应,并且协调者也挂了,这个时候会有什么情况呢,再加一个假设,其实比如这个一阶段其实是检验就失败的,理论上应该大家都释放资源,那么对于这种异常情况,其他的参与者就不知所措了,就傻傻地锁着资源阻塞着,那么三阶段提交的意义就出现了,把第一阶段拆开,那么即使在这个阶段出现上述的异常,即也不会锁定资源,同时参与者也有超时机制,在第二阶段锁定资源出现异常是,其他参与者节点等超时后就自动释放资源了,也就没啥问题了,不过对于那种异常恢复后的一些情况还是没有很好地解决,需要借助 zk 等,后面有空可以讲讲 paxos 跟 raft 等
只是这么平淡的生活就有一些自己比较心烦纠结的,之前有提到过的交通,最近似乎又发现了一点,就真相总是让人跌破眼镜,以前觉得我可能是胆子比较小,所以会觉得怎么路上这些电瓶都是这么肆无忌惮的往我冲过来,后面慢慢有一种借用电视剧读心神探的概念,安全距离,觉得大部分人跟我一样,骑电瓶车什么的总还是有个安全距离,只是可能这个安全距离对于不同的人不一样,那些骑电瓶车的潜意识里的安全距离是非常短,所以经常会骑车离着你非常近才会刹车,但是这个安全距离理论最近又被推翻了,因为经历过几次电瓶车就是已经跟你有身体接触了,但是没到把人撞倒的程度,似乎这些骑电瓶车的觉得步行的行人在人行道上是空气,蹭一下也无所谓,反正不能挡我的路,总感觉要不是我在前面骑自行车太慢挡着电瓶车,不然他们都能起飞去干掉 F35 解放湾湾了;
另一个问题应该是说我们交通规则普及的太少,虽然我们没有路权这个名词概念,但是其实是有这个优先级的,包括像杭州是以公交车在人行道礼让行人闻名的,其实这个文明的行为只限于人行道在直行路中间的,大部分在十字路口,右转的公交车很少会让直行人行道的,前提是直行的绿灯的时候,特别是像公交车这样,车身特别长,右转的时候会有比较大的死角,如果是公交车先转,行人或者自行车很容易被卷进去,非常危险的,私家车就更不用说了,反正右转即使人行道上人非常多要转的也是一秒都不等,所以我自己在开车的时候是尽量在右转的时候等人行道上的行人或者骑车的走完,因为总会觉得我是不是有点双标,骑车走路的时候希望开车的能按规则让我,自己开车的时候又想赶紧开走,所以在开车的时候尽量做到让行车和骑车的。
还有个其实是写着写着想起来的,比如我骑车左转的时候,因为我是左转到对角那就到了,跟那些左转后要再直行的不一样,我们应该在学车的时候也学过,超车要从左边超,但是往往那些骑电瓶车的在左转的时候会从我右边超过来再往左边撇过去,如果留的空间大还好,有些电瓶车就是如果车头超过了就不管他的车屁股,如果我不减速,自行车就被刮倒了,可能的确是别人就不是人,只要不把你撞倒就无所谓,反正为了你自己不被撞倒你肯定会让的。
]]>我的一些观点也在前面说了,恋爱到婚姻,即使物质没问题,经济没问题,也会有各种各样的问题,需要一起去解决,因为结婚就意味着需要相互扶持,而不是各取所需,可能我的要求比较高,后面男女主在分手后还一起住了一段时间,我原来还在想会不会通过这个方式让他们继续去磨合同步,只是我失望了,最后给个打分可能是 5 到 6 分吧,勉强及格,好的影视剧应该源于生活高于生活,这一部可能还比不上生活。
]]>前面其实是看的太阳的后裔,跟 LD 一起看的,之前其实算是看过一点,但是没有看的很完整,并且很多剧情也忘了,只是这个我我可能看得更少一点,因为最开始的时候觉得男主应该是男二,可能对长得这样的男主并且是这样的人设有点失望,感觉不是特别像个特种兵,但是由于本来也比较火,而且 LD 比较喜欢就从这个开始看了,有两个点是比较想说的
韩剧虽然被吐槽的很多,但是很多剧的质量,情节把控还是优于目前非常多国内剧的,相对来说剧情发展的前后承接不是那么硬凹出来的,而且人设都立得住,这个是非常重要的,很多国内剧怎么说呢,就是当爹的看起来就比儿子没大几岁,三四十岁的人去演一个十岁出头的小姑娘,除非容貌异常,比如刘晓庆这种,不然就会觉得导演在把我们观众当傻子。瞬间就没有想看下去的欲望了。
再一点就是情节是大众都能接受度比较高的,现在有很多普遍会找一些新奇的视角,比如卖腐,想某某令,两部都叫某某令,这其实是一个点,延伸出去就是跟前面说的一点有点类似,xx 老祖,人看着就二三十,叫 xx 老祖,(喜欢的人轻喷哈)然后名字有一堆,同一个人物一会叫这个名字,一会又叫另一个名字,然后一堆死表情。
因为今天有个特殊的事情发生,所以简短的写(shui)一篇了
]]>这次甚至更夸张,上次还让带回去,我准备好了系统镜像啥的,第二天装,这次直接带了两个老旧笔记本过来说让当天就装好,感觉有点像被当修电脑的使,又说这些电脑其实都不用了的,都是为了她们当医生的要每年看会课,然后只能用电脑浏览器看,结果都在用 360 浏览器,真的是万恶的 360,其实以前对 360 没啥坏印象,毕竟以前也经常用,只是对于这些老电脑,360 全家桶真的就是装了就废了,2G 的内存,开机就开着 360 安全卫士,360 杀毒,有一个还装了腾讯电脑管家,然后腾讯视频跟爱奇艺也开机启动了,然后还打开 360 浏览器看课,就算再好的系统也吃不消这么用,重装了系统,还是这么装这些东西,也是分分钟变卡,可惜他们都没啥这类概念。
对于他们要看的课,更搞笑的是,明明在页面上注明了说要使用 IE 浏览器,结果他们都在用 360 浏览器看,但是这个也不能完全怪他们,因为实在是现在的 IE 啥的也有开始不兼容 flash 的配置,需要开启兼容配置,但是只要开启了之后就可以直接用 IE 看,比 360 靠谱很多, 资源占用也比较少,360 估计是基于 chromium 加了很多内置的插件,本身 chromium 也是内存大户,但是说这些其实他们也不懂,总觉得找我免费装下系统能撑一段时间,反正对我来说也应该很简单(他们觉得),实际上开始工作以后,我自己想装个双系统都是上淘宝买别人的服务装的,台式机更是几年没动过系统了,因为要重装一大堆软件,数据备份啥的,还有驱动什么的,分区格式,那些驱动精灵啥的也都是越来越坑,一装就给你带一堆垃圾软件。
感悟是,总觉得学计算机的就应该会装系统,会修电脑,之前亲戚还拿着一个完全开不起来的笔记本让我来修,这真的是,我说可以找官方维修的,结果我说我搞不定,她直接觉得是修不好了,直接电脑都懒得拿回去了,后面又一次反复解释了才明白,另外就是 360 全家桶,别说老电脑了,新机器都不太吃得消。
]]>转籍其实是很方便的,在交警 12123 App 上申请就行了,在转籍以后,需要去实地验车,验车的话,在支付宝-杭州交警生活号里进行预约,找就近的车管所就好,需要准备一些东西,首先是行驶证,机动车登记证书,身份证,居住证,还有车上需要准备的东西是要有三脚架和反光背心,反光背心是最近几个月开始要的,问过之前去验车的只需要三脚架就好了,预约好了的话建议是赶上班时间越早越好,不然过去排队时间要很久,而且人多了以后会很乱,各种插队,而且有很多都是汽车销售,一个销售带着一堆车,我们附近那个进去的小路没一会就堵满车,进去需要先排队,然后扫码,接着交资料,这两个都排着队,如果去晚了就要排很久的队,交完资料才是排队等验车,验车就是打开引擎盖,有人会帮忙拓印发动机车架号,然后验车的会各种检查一下,车里面,还有后备箱,建议车内整理干净点,后备箱不要放杂物,检验完了之后,需要把三脚架跟反光背心放在后备箱盖子上,人在旁边拍个照,然后需要把车牌遮住后再拍个车子的照片,再之后就是去把车牌卸了,这个多吐槽下,那边应该是本来那边师傅帮忙卸车牌,结果他就说是教我们拆,虽然也不算难,但是不排除师傅有在偷懒,完了之后就是把旧车牌交回去,然后需要在手机上(警察叔叔 App)提交各种资料,包括身份证,行驶证,机动车登记证书,提交了之后就等寄车牌过来了。
这里面缺失的一个环节就是选号了,选号杭州有两个方式,一种就是根据交管局定期发布的选号号段,可以自定义拼 20 个号,在手机上的交警 12123 App 上可以三个一组的形式提交,如果有没被选走的,就可以预选到这个了,但是这种就是也需要有一定策略,最新出的号段能选中的概率大一点,然后数字全是 8,6 这种的肯定会一早就被选走,然后如果跟我一样可以提前选下尾号,因为尾号数字影响限号,我比较有可能周五回家,所以得避开 5,0 的,第二种就是 50 选一跟以前新车选号一样,就不介绍了。第一种选中了以后可以在前面交还旧车牌的时候填上等着寄过来了,因为我是第一种选中的,第二种也可以在手机上选,也在可以在交还车牌的时候现场选。
总体过程其实是 LD 在各种查资料跟帮我跑来跑去,要不是 LD,估计在交管局那边我就懵逼了,各种插队,而且车子开着车子,也不能随便跑,所以建议办这个的时候有个人一起比较好。
]]>net use 命令查看当前已经连接的net use [NETNAME] /deletenet use \\xxxxxxxx\f /deletenet use的命令使用方式可以参考
net use [{<DeviceName> | *}] [\\<ComputerName>\<ShareName>[\<volume>]] [{<Password> | *}]] [/user:[<DomainName>\]<UserName] >[/user:[<DottedDomainName>\]<UserName>] [/user: [<UserName@DottedDomainName>] [/savecred] [/smartcard] [{/delete | /persistent:{yes | no}}] |
Get-NetFirewallRule | Where-Object {$_.LocalPort -eq 22 -or $_.DisplayName -like "*SSH*"} | Select-Object DisplayName, Enabled, Action, Direction |
这个是查看的22端口或者名称带有SSH的
还可以直接看22端口的入站规则
Get-NetFirewallRule -Direction Inbound | Where-Object {$_.LocalPort -eq 22} | Select-Object DisplayName, Enabled, Action
确认下是否已有对应规则,没有的话可以通过下面的命令来添加
方法1:允许所有网络的ssh访问
New-NetFirewallRule -DisplayName "WSL2 SSH Inbound" -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow |
当然这样不太安全
所以我们最好是指定下来源ip
方法二:只允许局域网ip来访问
New-NetFirewallRule -DisplayName "WSL2 SSH LAN" -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow -RemoteAddress 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12 |
后面的网段可以根据所需限定
然后可以在所需机器进行访问验证
ssh -v user@192.168.xxx.xxx |
可以访问了的话说明我们这个就已经放行了,通过这个我们也能发现其实wsl2的这种方式一方面是让linux更加完整,但是对于所处的windows宿主机,想进行一些连通访问就会变得更加麻烦,也算是种取舍
]]>INFO Deploying: leancloud_counter_security_sync |
那么问题就差不多解决了,只是 traefik 这个问题还要看下,尝试把 traefik 的 docker-compose 启动起来,发现 80 端口被占了,
这时候就又是一个经典问题了,首先是找到哪个进程占用了这个端口
lsof -i:80 |
通过这个命令也可以,当然也可以通过 netstat,只是我一直记不住,用的不太多
发现是这个 apache2,就是重启ubuntu后默认启动的 apache 的 http 服务器,
只是这里需要注意下,它的服务名是 apache2 ,而不是httpd
所以可以通过
systemctl stop httpd |
来关闭,同时可以用
systemctl disable httpd |
直接把这个自启动的给干掉,省得每次重启都有这个问题,这一连串的排查还是比较有意思的
]]>首先第一种是直接使用maven命令
在项目目录下执行
mvn dependency:resolve -Dclassifier=sources |
命令,这样就会去下载这些依赖包的sources源码,等待命令构建完成就可以了
如果idea自动重建索引了就直接生效了,如果没有则需要choose sources
还有一种,找到idea的设置中的build工具,maven,import设置,勾选自动下载sources
可以勾选sources,就会在下载依赖包的时候就自动下载sources
点击idea的maven刷新按钮就会在下载依赖包的时候同代下载sources源码
这些前提是本身打包的时候是带上sources源码的,没有用一些混淆加密手段过
com.alibaba.dubbo.config.ServiceConfig#doExportUrlsFor1Protocol
private void doExportUrlsFor1Protocol(ProtocolConfig protocolConfig, List<URL> registryURLs) { |
通过jdk自带的方法 java.net.InetAddress#getLocalHost来获取本机地址,这样子对于容器来讲,获取到容器内部ip注册上去其实是没办法被调用到的,
而在之后的版本中例如dubbo 2.6.5,则可以通过在docker中设置环境变量的形式来注入docker所在的宿主机地址,
代码同样在com.alibaba.dubbo.config.ServiceConfig#doExportUrlsFor1Protocol这个方法中,但是获取host的方法变成了 com.alibaba.dubbo.config.ServiceConfig#findConfigedHosts
private String findConfigedHosts(ProtocolConfig protocolConfig, List<URL> registryURLs, Map<String, String> map) { |
String hostToRegistry = getValueFromConfig(protocolConfig, Constants.DUBBO_IP_TO_REGISTRY);
就是这一行,
private String getValueFromConfig(ProtocolConfig protocolConfig, String key) { |
也就是配置了DUBBO_IP_TO_REGISTRY这个环境变量
stream 中自带的 distinct 只能对元素进行去重
比如下面代码
public static void main(String[] args) { |
结果就是去了重的
[1, 2] |
但是当我的元素是个复杂对象,我想根据对象里的某个元素进行过滤的时候,就需要用到自定义的 distinctByKey 了,比如下面的想对 userId 进行去重
public static void main(String[] args) { |
结果就是
[StudentRecord(id=null, userId=11, courseId=100, score=100), StudentRecord(id=null, userId=11, courseId=101, score=100), StudentRecord(id=null, userId=12, courseId=100, score=100)] |
因为对象都不一样,所以就没法去重了,这里就需要用
public static <T> Predicate<T> distinctByKey( |
然后就可以用它来去重了
System.out.println(list.stream().filter(distinctByKey(StudentRecord::getUserId)).collect(Collectors.toList())); |
看下结果
[StudentRecord(id=null, userId=11, courseId=100, score=100), StudentRecord(id=null, userId=12, courseId=100, score=100)] |
但是说实在的这个功能感觉应该是 stream 默认给实现的
这个使用场景还是蛮多的,上面的场景里比如我要对 userId 进行分组,就一行代码就解决了
System.out.println(list.stream().collect(Collectors.groupingBy(StudentRecord::getUserId))); |
{11=[StudentRecord(id=null, userId=11, courseId=100, score=100), StudentRecord(id=null, userId=11, courseId=101, score=100)], 12=[StudentRecord(id=null, userId=12, courseId=100, score=100)]} |
很方便的变成了以 userId 作为 key,以相同 userId 的 StudentRecord 的 List 作为 value 的 map 结构
composer require phpunit/phpunitphpunit, 前面包就是通过 composer init 创建,装完依赖后就可以把自动加载代码生成下 composer dump-autoload. |
src/是源码,tests/是放的单测,比较重要的是phpunit.xml
|
其中bootstrap就是需要把依赖包的自动加载入口配上,因为这个作为一个package,也会指出命名空间
然后就是testsuite的路径,源码中
|
就是一个简单的重命名
然后test代码是这样,
|
setUp 跟 tearDown 就是初始化跟结束清理的,但是注意如果不指明 __DIR__ ,待会的目录就会在执行 vendor/bin/phpunit 下面,
或者也可以指定在一个 tmp/ 目录下
最后就可以通过vendor/bin/phpunit 来执行测试
执行结果
❯ vendor/bin/phpunit |
class RenameTest extends TestCase |
因为我是想写个重命名的小工具,希望通过setUp和tearDown做一些文件初始化和清理工作,但是我把两个case的初始化跟清理工作写到了单个setUp和tearDown中,这样就出现了异常的错误
通过上面的示例代码,可以看到执行结果
❯ vendor/bin/phpunit |
其实就是很简单的会在每个test方法前后都执行setUp和tearDown
获取list类型的所有元素,可以使用 lrange , 直接用lrange key 0 -1
比如
这里有一些方便的就是可以不用知道长度,直接全返回,或者如果想拿到特定区间的就可以直接指定起止范围,
这样就不用一个个pop出来
前面用了lrange取得了一个范围的数据,如果想将数据直接移除,那可以用 ltrim ,
这两个命令就可以从list里取出批量数据,并且能从list里删除这部分数据
zk1 192.168.2.1 |
在 zoo.cfg 中的配置就是如下
server.1=192.168.2.1:2888:3888 |
需要将集群迁移到 192.168.2.4(简称 zk4),192.168.2.5(简称 zk5),192.168.2.6(简称 zk6) 这三台机器上,目前新的这三台机器上是没有 zk 部署的, 我们想要的是数据不丢失,那主要考虑的就是滚动升级,这里我其实犯了几个错误,也特别说明下
首先我们想要新的三台机器加进去,所以我在zk4,zk5,zk6 的配置是这样
server.1=192.168.2.1:2888:3888 |
这样起来发现状态是该节点没起来,
PS:查看当前节点状态可以通过 ./zkServer.sh status 来查看
第一个问题是我需要一个myid文件,标识我是哪个节点,里面的内容就写 4或 5 或 6 这样就行了,并且这个文件的路径应该在配置文件中指定的dataDir=数据目录下
第二个问题是困扰我比较久的,我在按上面的配置启动节点后,发现这几个节点都是没起来的,并且有 FastLeaderElection@xxx - Notification time out: 60000 这个报错,一开始以为是网络不通,端口没开这些原因,检查了下都是通的,结果原因其实跟我之前的一个考虑是相关的,当有六个节点的时候,理论上需要有半数以上的节点可用,集群才会是健康的,但是按我这个方式起来,其实我配置了六个节点,但是其中三个都是不可用的(包括自身节点),那么它自然是没办法正常工作,所以这里其实也需要滚动添加,类似于这样
我的 zk4 的配置应该是这样
server.1=192.168.2.1:2888:3888 |
然后 zk5 的配置
server.1=192.168.2.1:2888:3888 |
接着 zk6 的配置就可以是全部了
server.1=192.168.2.1:2888:3888 |
然后为了集群完全更新,就继续在 zk4 和 zk5 加上其他节点,这样我的 6 节点集群就起来了
这里我踩了另外一个坑,或者说没搞清楚两种方式的差别,
首先说说我没采用的第一种方式,(也是比较合理的)其实上面这个集群有个明显的问题,老集群其实还是各自认了一个三节点的集群,其中 zk3 是主节点,对于 zk1,zk2,zk3 来说它们能看到的就只有这三个节点,对于后三个 zk4,zk5,zk6 节点来说他们能连上其余五个节点,可以认为这是个六节点的集群,那么比较合理的操作应该是在老的三节点上把后面三个也都加进来,即每个节点的配置里 server 都有 6 个,然后我再对老的节点进行下线,这里下线需要注意的比较理想的是下一个节点就要修改配置,挪掉下线的节点后进行一遍重启,比如我知道了集群中的 leader 是在 zk3 上面,那么我先将 zk1 和 zk2 下掉,那么在我将 zk1 下线的之后,我将其他的五个节点都删除 zk1 的配置,然后重启,这样其实不是必须,但相对会可靠些,理论上我也可以在下掉 zk1 和 zk2 之后再修改配置重启其余节点。而当只剩下 zk3,zk4,zk5,zk6 四个节点的集群后,并且每个节点里的配置也只有这四个 server,我再下线 zk3 这个 leader 的时候,就会进行选举,再选出新的 leader,因为刚好是三节点,同样保证了最小可用。
这也是我踩坑的一种方式,就是我没有修改原来三节点的配置,并且我一开始以为可以通过下线 zk1,zk2,zk3(进行选举)的方式完成下线,然后再进行重启,但是这种方式就是我上面说的,原来的三节点里我下掉 zk1 还是能够正常运行,但是我下线 zk2 的时候,这个集群就等于是挂了,小于最小可用了,这样三节点都挂了,而且对于新加入的三个节点来说,又回到了最初起不来一样状态,六节点里只有三节点在线,导致整个集群都挂了,所以对于我这样的操作来说,我需要滚动修改启动,在下线 zk1 的时候就需要把 zk4,zk5,zk6 中的 zk1 移除后重启,当然这样唯一的好处就是可以少重启几个,同样继续下线 zk2 的时候,把 zk2 移除掉再重启,其实在移除 zk1 后修改重启后,在下线 zk2 的时候,集群就会重新选举了,因为 zk2 下线的时候,zk3 还是会一起下线。这个是我们需要特别注意的
]]>docker exec -it mysql_server【docker容器名称/ID】 mysqldump -uroot -p123456【数据库密码】 test_db【数据库名称】 > /opt/sql_bak/test_db.sql【导出表格路径】 |
然后再在新的 mysql 容器中先 cp 到容器内,然后在 docker 内用 mysql 命令连接 mysql-server 以后用 source 将 sql 导进来
而像 traefik 本身其实是无状态的,只需要配置文件没有什么机器依赖就好,还有就是证书的更新,最后就是域名解析问题,修改解析就好
第三部分是 rustdesk 的迁移,这个其实就按官方文档来跑两个容器就好,hbbr 跟 hbbs 就好了,一个是 relay,一个是 id 服务器,不过这里有个问题我目前没看到怎么识别是否已经用到了这个,有种部署了但是不知道有没有用的尴尬,有知道的可以指导下
第四部分是 qinglong 的部署,这个也挺简单了,就是有个小问题,如果部署的订阅链接有 github 的就可以去站长的 ping 连接速度看看,自己配个 hosts 就会比较方便,不然经常容易拉不下来,还有就是要注意安全,至少要改强密码
caffeinate 这个命令是mac自带的,可以防止maccaffeinate -u -t 2 |
-u: 表示用户处于活动状态,此参数将打开屏幕并禁止屏幕进入空闲休眠。
-d:禁止屏幕休眠。
-i:禁止系统空闲休眠。
-m:禁止硬盘进入休眠。
-s:禁止系统进入睡眠状态,此参数仅在插上电源的时候才有效。
-t:指定命令有效的超时值,以秒为单位。
这样我们就能从rustdesk获得画面进行操作了,希望后面rustdesk能解决掉这个问题,因为这两种方式也不是很完善,如果只有纯远程的话就没办法了
TCP 21114-21119 |
测试有没有开启可以使用这个工具网站 CanYouSeeMe.org ,或者用另一台机器telnet下
需要部署的服务有两个
hbbs - RustDesk ID/Rendezvous server id服务
hbbr - RustDesk Relay server 中继服务
这里使用docker来部署,比较简单,先拉取镜像,没错就一个
sudo docker image pull rustdesk/rustdesk-server |
这边建议创建个rustdesk目录,进入目录后再启动下面的服务
先启动hbbs
sudo docker run --name hbbs -p 21115:21115 -p 21116:21116 -p 21116:21116/udp -p 21118:21118 -v `pwd`:/root -td --net=host rustdesk/rustdesk-server hbbs |
使用 --net=host 是为了让server拿到连接进入的真实来源ip
然后再启动hbbr
sudo docker run --name hbbr -p 21117:21117 -p 21119:21119 -v `pwd`:/root -td --net=host rustdesk/rustdesk-server hbbr |
接下来进到刚才建的目录,会看到有个一对公私钥,把公钥内容保存下来
然后就是客户端登录了,以mac为例
点击这边三点,再点击修改中继设置
在弹出窗口
ID服务器跟中继服务器框填入前面部署服务的服务器外网ip,在Key框里把刚才保存的公钥填进去
每个需要连接的客户端都需要这么设置,然后就可以使用自己的服务器作为ID跟中继服务器了,不会受官方关停国内服务影响
在开始迁移前,先做一下准备
rclone config 开始远程存储配置n 创建新的远程存储cosAmazon S3 兼容模式(选项编号可能因 rclone 版本而异)access_key_id 和 secret_access_key(从腾讯云控制台获取)n 创建新的远程存储r2Amazon S3 兼容模式access_key_id 和 secret_access_key(从 Cloudflare 控制台获取)https://<account_id>.r2.cloudflarestorage.com)完成配置后,使用以下命令执行迁移:
rclone copy cos:mystore-xxxxxxx/img/ r2:img/ --progress |
上述命令将把腾讯云 COS 中 mystore-xxxxxxx 存储桶下的 img 目录中的所有文件复制到 Cloudflare R2 的 img 存储桶中。添加的 --progress 参数可以显示迁移进度。
为了获得更好的迁移体验,您可以考虑以下高级选项:
--transfers=N 参数设置并行传输数量,加快迁移速度--checkers=N 参数设置并行检查数量--dry-run 参数测试迁移过程而不实际复制文件--log-file=FILE 参数将迁移日志保存到文件中例如:
rclone copy cos:mystore-xxxxxxx/img/ r2:img/ --progress --transfers=4 --checkers=8 --stats=10s |
迁移完成后,可以使用以下命令验证两边的文件是否一致:
rclone check cos:mystore-xxxxxxx/img/ r2:img/ --one-way |
通过 rclone 这一强大工具,可以轻松实现云存储服务之间的数据迁移。Cloudflare R2 提供了稳定可靠的对象存储服务,同时其无出站流量费用的特性也使其成为图库存储的理想选择。
]]>乌丝兰玛是个贯穿两部,甚至在蛮荒的最后还要再搞事情,极其坚定的自以为是的大 boss,其实除了最后被我们的主人公打败,前面几乎就是无所不能,下了一盘无比巨大的棋,主人公都只是其中一个棋子和意外,但是正如很多反派,一直以来都是背着一个信念,并且这个所谓的信念是比较正义的,只是为了这个正义的信念和目标却做了各种丧尽天良的事情,说起来跟灭霸有点像,为了环保哈哈,相对来说感觉姬远玄也只是个最大牌的工具人,或者说是中间人,深爱的妹妹冰夷也意外被蚩尤怒拿一血。
但是中间那个赤霞仙子一定要给烈烟石的心上锁,导致最后认不出来蚩尤,也间接导致了蚩尤被杀,如果不考虑最后情节或者推动故事的需求,这个还是我很讨厌的,有点类似于《驴得水》里那个校长,看着貌似是个正常的,做的事情也是正派,但是其实是害人不浅,即使南阳仙子因此被抛进了火山,那也是有贱人在那挑食,并且赤松子是赤飚怒的儿子,烈烟石跟蚩尤又没这层关系,就很像倚天屠龙记里的灭绝师太和极品家丁里的那个玉德仙坊的院主,后者还好一些,前者几乎就是导致周芷若一生悲剧的始作俑者,自己偏执的善恶观,还要给徒弟灌输如此恶毒的理念和让她立下像紧箍咒似的誓言,在人一生中本来就有很多不能如愿的,又被最亲最尊敬的人下了这样的紧箍咒,人生的不幸也加倍了。
似乎习惯了总要有个总结的,想说的应该是我觉得这些剧也好,书也好,我觉得最坏的人可能是大部分人眼中的一些次要人物,或者至少大 boss 才是最坏的人,当然这个坏也不是严格的二分法,只是我觉得最让我觉得负面的人物,这些人可能看起来情景出现的不多,只是说了很少的话,做了很少的事,但是在我看来却做了最大的恶。
]]>对对面这户人家的印象,就是对面的老头子经常是我出门上班去了他回来,看着他颤颤巍巍地走楼梯,我看到了都靠边走,而且有几次还听见好像是他儿子在说他,”年假这么大了,还是少出去吧”,说实话除了这次的事情,之前就有一次水管阀门爆裂了,算是有点交集,那次大概是去年冬天,天气已经很冷了,我们周日下午回来看到楼梯有点湿,但是没什么特别的异常就没怎么注意,到晚上洗完澡,楼下的邻居就来敲门,说我们门外的水表那一直在流水,出门一看真的是懵了,外面水表那在哗哗哗地流水,导致楼梯那就跟水帘洞一样,仔细看看是对面家的水表阀门那在漏水,我只能先用塑料袋包一下,然后大冬天(刚洗完澡)穿着凉拖跑下去找物业保安,走到一楼的时候发现水一直流到一楼了,楼梯上都是水流下来,五楼那是最惨的,感觉门框周边都浸透了,五楼的也是态度比较差的让我一定要把水弄好了,但是前面也说了谁是从对门那户的水表阀那出来的,理论上应该让对面的处理,结果我敲门敲了半天对面都没反应,想着我放着不管也不太好,就去找了物业保安,保安上来看了只能先把总阀关了,我也打电话给维修自来水管的,自来水公司的人过了会也是真的来修了,我那会是挺怕不来修,自来水公司的师傅到了以后拿开一看是对面那户的有个阀门估计是自己换上去的,跟我们这的完全不一样,看上去就比较劣质,师傅也挺气的,大晚上被叫过来,我又尝试着去敲门也还是没人应,也没办法,对面老人家我敲太响到时候出来说我吓到他们啥的,第二天去说也没现场了。
前面的这件事是个重要铺垫,前几天 LD 下班后把厨余垃圾套好袋子放在门口,打算等我下班了因为要去做核酸(hz 48 小时核酸)顺便带下去,结果到了七点多,说对面的老太太在那疯狂砸门了,LD 被吓到了不敢开门,老太太在外面一边砸门一边骂,“你们年轻人怎么素质这么差”(他们家也经常在门口放垃圾,我们刚来住的时候在楼梯转角他们就放这个废弃的洗衣机,每次走楼梯带点东西都要小心翼翼地走,不然都过不去,然后我赶紧赶回去,结果她听到我回家了,还特意开门继续骂,“你们年轻人怎么素质这么差,垃圾放在这里”,我说我们刚才放在这,打算待会做核酸的时候去扔掉,结果他们家老头,都已经没了牙齿,在那瞪大眼睛说,“你们早上就放在这了的,”我说是LD 刚才下班了放的,争论了一会,我说这个事情我们门口放了垃圾,这会我就去扔掉了,但是你们家老太太这么砸门总不太好,像之前门口水管爆掉了,我敲了门没人应,我也没要砸门一定把你们叫醒,结果老头老太说我们的水管从来没换过,不可能破的(其实到这,再往后说就没意思了,跟这么不要脸的人说多了也只是瞎扯),一会又回到这个垃圾的问题,那个老头说“你们昨天就放在这里了的”,睁着眼说瞎话可真是 666,感觉不是老太太拦着点他马上就要冲上来揍我了一样,事后我想想,这种情况我大概只能躺地上装死了,当这个事情发生之前我真的快把前面说的事情(水管阀坏了)给忘了,虽然这是理论上不该我来处理,除非是老头老太太请求我帮忙,这事后面我也从没说起过,本来完全没交集,对他们的是怎么样的人也没概念,总觉得年纪大了可能还比较心宽和蔼点,结果没想到就是一典型的坏人变老了,我说你们这么砸门,我老婆都被吓得不敢开门,结果对面老头老太太的儿子也出来了说,“我们就是敲下门,我母亲是机关单位退休的,所以肯定不会敲门很大声的,你老婆觉得吓到了是你们人生观价值观有问题”,听到这话我差点笑出来,连着两个可笑至极的脑残逻辑,无语他妈给无语开门,无语到家了。对门家我们之前有个印象就是因为我们都是顶楼,这边老小区以前都是把前后阳台包进来的,然后社区就来咨询大家的意见是不是统一把包进来的违建拆掉,还特地上来六楼跟他们说,结果对面的老头就说,“我要去住建局投诉你们”,本来这个事情是违法的,但是社区的意思也是征求各位业主的意见,结果感觉是社区上门强拆了一样,为老不尊,坏人变老了的典范了。
]]>那位大哥,骑电瓶车一前一后带着两个娃,在非机动车道靠右边行驶,肉眼估计是在我右前方大概十几米的距离,不知道是小孩不舒服了还是啥,想下来还是就在跟他爹玩耍,我算是比较谨慎骑车的,看到这种情况已经准备好捏刹车了,但是也没想到这个娃这么神,差不多能并排四五辆电瓶车的非机动车道,直接从他爸的车下来跑到了非机动车道的最左边,前面我铺垫了电瓶车 25 码,换算一下大概 1 秒能前进 7 米,我是直接把刹车捏死了,才勉强避免撞上这个小孩,并且当时的情况本来我左后方有另一个大哥是想从我左边超过去,因为我刹车了他也赶紧刹车。
现在我们做个假设,假如我刹车不够及时,撞上了这个小孩,会是啥后果呢,小孩人没事还好,即使没事也免不了大吵一架,说我骑车不看前面,然后去医院做检查,负责医药费,如果是有点啥伤了,这事估计是没完了,我是心里一阵后怕。
说实话是张口快骂人了,“怎么带小孩的”,结果那大哥竟然还是那套话术,“你们骑车不会慢点的啊,说一下就好了啊,用得着这么说吗”,我是真的被这位的逻辑给打败了,还好是想超我车那大哥刹住车了,他要是刹不住呢,把我撞了我怪谁?这不是追尾事件,是 zhizhang 大哥的小孩鬼探头,下个电瓶车就下车,下来就往另一边跑,我们尽力刹车没撞到这小孩,说他没管好小孩这大哥还觉得自己委屈了?结果我倒是想骂脏话了,结果我左后方的的大哥就跟他说“你这么教小孩教得真好,你真厉害”,果然在中国还是不能好好说话,阴阳怪气才是王道,我前面也说了真的是后怕,为什么我从头到尾都没有说这个小孩不对,我是觉得这个年纪的小孩(估摸着也就五六岁或者再大个一两岁)这种安全意识应该是要父母和学校老师一起教育培养的,在路上不能这么随便乱跑,即使别人撞了他,别人有责任,那小孩的生理伤痛和心理伤害,父母也肯定要心疼的吧,另外对我们来说前面也说了,真的撞到了我们也是很难受的,这个社会里真的是自私自利的人太多了,平时让外卖小哥送爬下楼梯送上来外卖都觉得挺抱歉的,每次的接过来都说谢谢,人家也不容易,换在有些人身上大概会觉得自己花了钱就是大爷,给我送上来是必须的。
]]>show slave status 结果里的 Seconds_Behind_Master 指标,那这第一种情况就否定掉了,这里其实是犯了个错误,应该去从库看这个延迟的,不过对于阿里云来说在 rds 监控是看不到从库的监控的,只能到 das,也就是阿里云的数据库自治服务可以看到,这里能看到从库的延迟监控,发现的确有这么高,这样就要考虑为啥会出现这种情况,阿里云同学反馈的是这段时间的 iops 很高,并且 cpu 也比较高,让我排查下 binlog,这里就碰到一个小问题,阿里云 rds 的线上实例我们没法在本地连接,并且密码也是在代码里加密过的,去服务器上连接一方面需要装 mysql 客户端,另一方面是怕拉取日志会有性能影响,幸好阿里云这点做的比较好,在 rds 的”备份恢复”–> “日志备份”菜单里可以找到binlog 文件, 在这里其实大致就发现了问题,因为出问题的时间段内升成 binlog 的量大大超过其他时间段,然后通过内网下载后就可以对 binlog 进行分析了,这里我们用到了 mysqlbinlog 工具,主要就是找具体是哪些写入导致这个问题,mysqlbinlog 可以在 mysql 官网下载 mysql 的压缩包,注意是压缩包,这样解压了直接用就好了,不用完整安装 mysql,一般我们需要对 binlog 进行 base64 的反编码,
./mysqlbinlog -vv --base64-output=decode-rows mysql-bin.xxxx | less |
这样查看里面的具体信息,发现是大量的 insert 数据,再经过排查发现同一个 binlog 文件近 500M 全是同一个表的数据插入,再根据表对应的业务查找发现是有个业务逻辑会在这个时间点全量删除后在生成插入数据,后续需要进行优化
]]>













































的url进行配置,以及确定模型名是 deepseek-r1-250120


]]>




,这样就不会被覆盖
]]>























, 正好又解决了下



