说实话，我也没想到我会在博客上分享生活琐事，只是突然觉得，偶尔分享分享不那么重要的私事好像也没什么。

叙旧

事情的起因是我的小米平板5pro，21年买的，那时候米子刚重新开了平板产品线，那时候幻想的挺好的，我要用平板用来学习、看书，偶尔再刷刷视频。有句名言叫做买前生产力，买后爱奇艺，对此我不能说嗤之以鼻吧，算是有点认可。
我刚工作第二个月，我用我第一个月的工资，买了一部，那时候售价2800左右吧，还挺开心的，算是工作之后第一次买东西给自己。不知不觉竟然用了4年多了，还挺耐用。
平板也逐步成为了我睡前看看番剧的工具，真正沦落到爱奇艺工具hhh。不过就是系统偶尔有点小毛病，不过都用米了，还要啥自行车？物理设备上，自从哪一次平板从床上跌落之后，上音量键就坏了，那时候我也没管，因为我可以用下音量键再配合触控来调节音量。应该是去年年底，我发现我的下音量键也坏了，彻底按不了了，有一说一完全可以通过下拉任务栏调节音量，而且从操作时间上没什么不同，但是我就是觉得膈应。因此我决定维修下平板。

经过

春节前正好有一天年假得用完，正好约的那天线下维修，结果店里打电话过来说没有备件，说能不能等两天，我说可能得过年后了，第一次维修先告一段落。过年的时候，我决定提前几天回杭州，正好约维修。
维修当天，我是下午一点去线下店，店里当时有两个老哥也是维修的，师傅说要可能要一个小时往上了，说可以稍晚再过来取，我说没问题我现场等，结果等了差不多2.5小时才修完了。维修前还告诉我需要撕掉钢化膜，我说没问题。除去前面等待的几个人，整个维修过程大概要1个小时左右，整个维修过程中能听到师傅在打电话请教其他人。
维修完成后，当场我检测了音量键，确实修复完成了，我也没在意，一共付款70块钱，顺带27块买了条数据线，我就回去了。回到家后，打开屏幕和设置，结果发现屏幕出现了一些褶皱，我打开了CIT，查看了白屏测试，确实非常明显。我第一时间拨打了线下店的电话，询问怎么回事，师傅给我答复是正常的，使用时正常磨损，但问题是我不记得我之前有啊，他说可以再回去线下店看看，我又回去了，结果现场查看后他还是说是日常使用磨损，我那时陷入疑惑，难道之前真的有吗？因为我日常都使用的黑夜模式，这种模式下根本看不出来。
然后就又回家了。晚上睡前看视频时，倒是不怎么影响，因为大部分视频都不可能有纯白背景，但是进入设置后十分明显，我越想越不对，结果网上搜了一下，屏幕褶皱是什么情况，结果翻到一篇帖子，说苹果维修由于师傅开屏器温度设置不对，导致LCD屏出现褶皱。我开始观察我平板的褶皱，还真发现蹊跷，褶皱上下是对齐的，说明这真的是线下店开屏的问题。

再次维修

于是，我决定再次维修，但这次我决定走线上维修，原因有二，一是我也理解线下店打工人的不易，二是线下店毕竟是真人PK我比较害怕。所以我拍摄了相关照片，将平板寄修给小米浙江维修中心。于是便开始了我的维权之路。
维修中心1号师傅检测后，确定是有类似问题，需要换屏，但是他要价800多，我说太贵了，这是你们维修的问题为啥要我承担费用，他说他们维修中心和网点是不同的网点，网点的问题他们不承担的，我觉得他说的有道理。过程中我问他你看褶皱是不是开屏温度过高导致的，他说他没法判断，还说可以打九折，我说我不接受，平板先放他们那，我走线上客服看看，师傅说可以，系统上显示的就是客户不认可检测结果。
由于我的售后维修都是小米商城的线上申请，我直接找客服，说了相关的事情，第二天寄修中心客服又给我打电话了，说可以7折换屏，我说我不同意。同时客服说会让线下店找我沟通。第三天傍晚，线下店之前的师傅确实电话我了，说可以5折换屏，我说不行，我的诉求就是免费换屏，你们的责任为啥要我承担。由于那时候是周五傍晚，赶去一个饭局，就没多聊。
结束后我还和姚老师吐槽，看看最后会不会免费给我修，身为一个十年米粉，没想到小米的售后还挺扯。不过线上客服确实干事，有问题就会解决。但是维权周期实在太久了，如果急用的话真的会气死。姚老师还评判我，说我这种十年米粉喂了狗的观点就是典型的渣女思维，DS说，这种隐含着一种“我长期支持你、付出感情和金钱，你就必须永远让我满意，否则你就是辜负我”的逻辑。我思考了下，确实没错，但是如果这次小米没给我一个满意的结果，真的挺掉粉的，虽然我又买了一个全新的平板，真的像舔狗一样。
周一一到，由于我周末又去催线上客服了，线下店再次打电话给我，说可以免费维修，并表示了道歉。我登录商城查看维修单，发现平板已经维修完成了。
至此，我的这次维修之路终于结束了。

感想

如果提前知道这个维修会出这么多事，我宁愿不维修。说实话，我知道对线下店的师傅会有影响，甚至维修的费用都可能是他们自掏腰包，但是我还是决定维护自己的权益，说实话，我已经好几年没干这种事了，这种事是我高中会干的事，高中取快递的时候发现快递站点对快递是扔的，我直接投诉了，现在回想起来，还挺好笑的，明明不关我事，但我还是去做了，那时候觉得捍卫自己权益的事情好酷啊。类似的事情还有很多，比如投诉国家电网、给校长投诉高中老师等等。
我已经低调了很多年，原因是我明白了很多事情不是非黑即白，打工后明白了打工人的不容易等等。但有些事情涉及自己并且退一步越想越气时，我还是会出手去解决这件事，去正常维护自己的权益。

后续

4月6日，我看到了一个关于小米售后的视频新机不幸中奖了…带大家体验一下小米线上售后
真的也是感触颇深，但我知道终究会解决的。这无关普通人还是UP主，这取决于你是否懂得去争取。只是时效问题，这真的是我想吐槽小米的一点。

转眼间又到了这个时候，2025年最后一个月，人生又过了一年！这一年好像发生了很多，又好像十分平淡。又或许每天都在行尸走肉当中。总是想提笔写点什么，但又不知道如何下笔。心中好像有很多想法，但这些想法又好像一团浆糊，黏在脑子里，说不出写不出，只能影响思考。但我还是认为应该留下点什么，在2025年的年底回忆这一年，反思过往。

那就来倒叙吧。先说说最近。11、12月比较重要的一件事是软考，只能说可惜。我其实知道自己会没过，所以成绩出来的一周我都没查，就在今天，我决定面对自己的失败。客观题44分，仅仅只差一分，案例与论文没有任何问题。很难受，说实话。我感觉自己对这个考试有点魔怔了，我想从这个考试中来肯定自己。但我想到姚老师和我说的一句话，只有无能的人才从需要通过各种考试肯定自己。是的，我认同，但我也难以接受。人作为社会性动物，来自外部的肯定对人自身是有积极作用的。你说这个证书对我有用吗，没有任何实质性的作用。那我为什么要考这个考试呢？因为我还是想从外部证明自己不比其他人差。

所以，我认了，我承认现阶段的自己还是太狂了，一个本科毕业刚4年的小屁孩，就想冲击国内计算机最高的考试，是的，我有点膨胀了。从另一方面来看，我去年到现在考了三次，第一次只靠自己刷题，客观题差8分。第二次开始我看了点课程，但是上半年很忙，结果不仅客观题还是差8分，案例还差了3分。这一次，客观题差1分，案例超过了及格线7分。虽然今年下半年难度偏低，但整体来看自己是在进步的，运气稍差一点，但我也要承认运气也是实力的一部分。虽然明年上半年我不一定会参加考试，下次多花点时间学习，争取下次考试考过。

聊完了软考，再聊聊生活。最近买了一个新耳机，索尼XM5，1465拿下，听音乐很赞，但是我开心不起来。不知道从什么时候开始，我开始感受不到生活上的一些快乐，买东西？打游戏？又或者出去吃饭？我感觉很难填满心中的某些空缺。我时常会想，我是不是抑郁了？事实上可能确实有点。消费只是为了让自己感到快乐这句话一点没错。我经常晚上睡觉前会刷刷购物软件，但是我也不买，有一段时间，我每晚都刷运动相机，想买，但是理性的思维让我停下了消费。最后我还是放弃了 。回到耳机，这个也是自己非常想买，线下也尝试了，最后还是拿下了。刚收到还是比较激动，后面就平常心了。回想起来，我已经好几次进行了小额度的冲动消费，眼部按摩仪、除螨仪等等。。。你说这些东西有用吧，好像又没用。但买了就买了，整体我还是满意的。

11月份，我正式入职一周年，我的感受只有一个，那就是终于熬了一年。拿了个钥匙扣，平平无奇。我不想在开头就吐槽工作，这块就留到最后吧。这个月很忙，感觉很多事，伴随着大大小小的感冒。流感太多，身体太差。
再聊聊游戏，11月最遗憾的还是崩铁，陪了一整年的翁星故事终于落下帷幕，有遗憾，有美好，但我觉得编剧老师说的对，和这个故事一起成长的自己，才是那个最值得珍惜的东西。还有配套的音乐，应该是近一个月我最喜欢的音乐之一。

10月，因为工作的原因，我回了趟老东家。回去一趟，心情还是比较复杂，以专家的title再次去交流。回过头看，我当初离开，也是年少轻狂，觉得自己牛逼的不行，内部的混沌不适合我。因此我毅然决然离开。依结果来看，工作的状态也没有多大改变，又或许工作本身就是这样。工作只是赚钱的手段之一，并不能在工作中寻找自我。我想我也逐渐懂得这个道理了。

国庆假期，因为有天值班，没回家，当然也是借口，想在宿舍躺尸。6号去了五云山爬山，累得半死。感觉身体越来越差，还是得多锻炼。5号骑着我的电动车在良渚附近转了30多km，很爽很自由，我很喜欢那种风吹在自己身上的感觉，当然冬天除外。一直想去考摩托车驾照，可惜杭州禁摩，不然我真的想整一辆去旅游，摩旅，好像也不错。

9月，买了个骑行支架，本来以为能把手机架在电动车拍点VLOG，结果发现我想多了，抖得不成样子，那个时候也在考虑运动相机，但是我最终还是放弃了，用手机都不愿意拍，那么我也不相信运动相机会拍。国庆前还和几个兄弟吃了一个日式烤肉？等了2小时，好像那就那样，让我吃第二次也不好说。9月还有一件事，就是认识了半年的同事离职了，从4月份共事到9月正好半年，他离职去某大厂了估计，追求他所谓的提升。但说实话我知道他只是对现在的老板不满而已，边缘下属+傻逼老板，buff实在是叠满了。他离职前我还专门和他聊过，外面也不一定好，你所谓的提升都只是表象，提升了五六千块又能咋样？不过有些事没有自己体会是不会懂的，去年离职后，我感觉自己又悟了不少。后面又陆陆续续和他聊天，他说现在天天加班到晚上9点，相当于增加的工资就是他的加班费了。他作为本地人其实钱拿少点早点下班就行了，没必要一直卷，我说他是没吃过苦的，他说是的，从第一家公司到之前为止，他基本上没有高强度上班，也祝他能找到平衡吧。
9月初血月，熬了个小夜，拍了照片，好像也就那样，等待的时候日常刷手机，刷到一句话，”去罗马的路很多，可以搭飞机，可以绕到北极，但也可以不去罗马。“，确实令我思考许久，但不去罗马不相当我放弃了目标吗？又或者这只是人生中的一个小插曲，不值一提呢？我想我还得思考几年。
9月4号，生日，今年生日我也写了一篇文章，碎碎念，那时候整个人还是比较消极的，当然现在也是消极的，只不过有些东西通顺了不少，但还有些东西还得继续思考。

8月，遇到一个工作上的难题，我排查了两个月，才最终解决。不得不说，当去解决难题并且解决了的感觉确实很爽，之前为什么喜欢编程，因为编程就是一个个问题的集合，当我完成编码看着他们运行起来，那感觉确实很开心。运维也是一样，不过运维解决问题基本上是系统要有问题了，压力相对大点。8月还出了一件事，就是封禁了443端口，导致跨境网站都用不了，有人说是临时工，但我觉得应该也是在测试什么导致手滑配置错误了。这件事之后我才发现原来源码已经泄漏了，大家都在研究，真的好家伙，我也偷偷下载了，不过除了一些文档外，代码我啥都没看。
这个月团队还去了团建，青岛，滨海城市，感觉和泉州差不多，吃了海鲜，自驾了环海公路，第一次坐了绿皮火车过夜，基本整夜无眠，回来第一次坐了商务座，好像也没啥。团建没和老板行动都是开心的，总体来说还不错。

7月，星铁送我的纪念册到了，不过直到写这篇文章的时候，我才发现我包装都没拆，米哈游每年都会送点东西，这点还不错。这个月还和小伙伴一起去了西湖的宝石山，爬山确实累，不过还是得多锻炼，今年又胖了不少，现在已经60多kg了。。。这个月还请小伙伴吃了泉州菜，宋小瑾这家店真的见证了它，从我们小镇上的一个小餐馆，逐步开成了连锁，这个老板也是牛逼。
7月13日，那天很晚的时候有一个私人号码给我打电话，说他是警察，怀疑我被诈骗了，让我不要转账，我啥操作都没呢，他说我支付宝有消息送到他们系统里。那天我确实尝试把银行卡绑定到paypal，但是无法支付。随后，公司的应急响应中心也给我发消息，说公安推送我有被诈骗的风险，说实话，我害怕的不是我的钱被骗，而是我做了什么操作，后台都看的清清楚楚，美名其曰反诈，我背后一阵发凉。
7月初，和帅哥一起去了趟义乌，看了小商品，帅哥想做网上玩偶、盲盒，问我有没有兴趣，基本没啥成本，找代发就行，只要会运营账号，我说可以，一起去义乌看看有没有渠道，还让他请了两顿饭。后面又找了两个小伙伴，揍了1w块钱，每个人搞一个平台的店铺，把货铺开，尝试运营账号，由于他老婆是视频剪辑，因此视频基本都是他老婆剪，我们发到平台上。结果做了两个月，他要结婚买房装修啥的太忙了，就没做了，还有9千多块在我的账户上。也许哪一天又重启了，但说实话这些钱在我这压力也挺大。我也不好去投资啥的。

6月，去吃了一家还行的新疆料理，离职的那位同事一起带吃，确实还行，但是感觉羊肉太油腻了。6月和帅哥还一起做了一个爬虫项目，本来我是友情支持，但帅哥非得给我钱，好像给了我几千块，我也坳不过收了，虽然交付后账号都被封了，但老板也没说啥，本来帅哥还想靠着这条路致富，结果出身未捷身先死。也算是一个人生的小插曲，大起大落。
这个月还看了一本书，叫停止精神内耗，这本书的很多观点我都认同。”因为追求太多，我们的目光总是投向遥不可及的未来，却看不到身边的美好。年轻时，不懂珍惜，将时间都花在虚无的追求上，随着年龄的增长，这些东西变得毫无实用价值买新的焦虑又会产生，我们要把目光投向未来，看到问题的本质，珍惜当下。“、”我们之所以痛苦，是因为追求过多。我们不该因为失去什么而感到不幸，学会选择，有所放弃。有些东西永远无法拥有，有些人最终会从熟悉到陌生。如果不愿面对现实，只会错过当前的幸福。“
类似的观点还有很多，如果真的有人能看到这的话，我建议你去看看这本书。

5月底，端午节回了趟老家，老爹又要出国，想着回家看看，家里人也挺不容易的，当初为何毕业后想工作赚钱，其实也有这个理由，养活自己。后面其实老爹老妈都聊过，他们都知道我的想法（想出来赚钱），我的大学生活还是比较拮据的，没有特别多的活动，我最大的开销就是买那台笔记本，花了7000块钱，其中还有几千块是我高中的时候攒下来的。这次回去，老家又改变了不少，各种旅游设施都建好了，老家被拆的房子也被改造成休息点了，住了十几年的房子，想想也挺感慨的。
这个月底，还参加了上半年的软考，难度比下半年高很多，结果也是没通过，不提也罢。劳动节假期，和大学的好兄弟一起去了青山湖骑行了30km，感觉很爽，还是第一次尝试骑行那么远，花了3个多小时好像，没啥特别累的感觉，路上看了很多风景，产生用无线电呼叫附近的火腿，但是没有得到回应。假期还发生了一件令我很不爽的工作上的事，老板真的傻逼，对外软弱，对内重拳出击，也因此我和北区团队结下了梁子，这时也在我心里种下了一枚离职的种子。

4月底，由于团队合并，老板让我去新团队，因此去了趟广州，认识了另一个团队的大佬们，餐桌上有说有笑，现在回忆起来也是真够搞笑的，在那时吃饭的成员中，两个转岗，一个离职，哈哈哈，那时候大家不知道是怎么想的。也正是这次的广州出差之行，让我知道老板是怎么样的人，让我和另一个同学住一间双人间，自己却住豪华酒店，啧啧啧。据另一个同学说，他出差的时候想住近一点，结果2个人住的总额超了单人标准，老板还让他们付额外的钱。。。令人震惊。广州，挺好的一个城市，和北京的同事去了广州塔，拍了一些照片，和他聊了聊，北京买房生娃感觉他也挺不容易的。这次还是我第一次坐飞机，挺普通的出行方式，但愿不要出现意外情况。
这个月，拿到了我的无线电执照，第一次参加了无线电点名，这里是BG5FFU，很激动，有时候觉得有一群志同道合的网友一起喜欢一件事感觉也很不错，只可惜，我好久没有打开过我的无线电手台了。写下这段话的时候，我把我的手台重新插上了电源，看看能否收到来自其他火腿的信息。

3月下旬，去了趟颈椎科推拿，感觉脖子很僵硬，好久没去了，最近好像又是之前的感觉，脖子很酸，找个时间需要再去一趟。这个月还参加了公司的培训，入职半年后第一次参加了新人营，没有什么特别大的归属感对于公司，我感觉地位很低，也被人看不起。姚老师说，自己应该被自己定义，而不是通过其他人评价你来获得。也没问题，但这个社会是群居的，很难逃过别人的评价，但只是因为某一个点不达标就被贬低，这社会真的病了。
这个月还去考了无线电执照，学习了半个月的系统知识，看了好几款手台，最终以96分通过了考试，也算顺利。以无线电为契机，我也学习了很多知识、工具、软件等等，这个圈子很小众，但是很多人都很和善。

2月，春节后回杭州，处于不想上班的氛围中，偶尔请朋友或者朋友请我吃饭，这个月好像很平淡，帮客户解决了很多问题，我想我那时候应该是迷茫的。

1月底，春节会老家，一大群亲戚去了古城上徒步，拍了很多照片，回看的时候感觉还在昨天，前面提到端午节的时候，说老家的旅游越办越好了，其实我每次回老家都有这样的感觉，我感觉大半年甚至一整年才回去一趟让我跟不上，很多昔日的地点当我再踏上时他却是另一番景色，物是人非。我时常在想原理家乡的我，为何在杭州，以后如何发展，如何照顾老人。今年老妈搬到了新家，装修的很好，她说是为了将来的我结婚用的，我说还早，她总会反驳我说隔壁谁谁谁小孩都有了，你还在单身。其实这个话题我也想聊聊，但说到底无非觉得比较自由，加上自己还是比较懒的，除了工作外只想睡觉打游戏，谈恋爱结婚在我想法中优先级是比较低的。

碎碎念

磨了好久，终于把流水账磨完了，有一说一，拖延症还是比较严重，是个坏习惯，总是把一些不那么重要的事向后推，宁愿去玩游戏、刷视频或者看书。不过还是主要不知道怎么去总结这一年的事情。发生了好多但又好像没有可以刻印在人生轨迹中的重大事件，一切都很平淡。姚老师说，牛马才会反思总结，我四分之三认可吧，不可否认，的确牛马总是喜欢反思自己的问题，试图从自身去解释整个世界，也许是被这个社会PUA惯了，从小的惯性思维。但还有四分之一也不能说否认吧，我觉得人生还是每隔一段时间需要回看下发生了什么，其实我也是在写这段话的时候才意识到，好多发生的事我的记忆好模糊，因为他们可能是一些微不足道的小事，或者说没有在人生中留下浓墨重彩，它们带给我的是那段时间的感动。也许其实每件发生的事对于人来说都是微不足道的呢？记忆总有一天会忘却，唯有文字可以记录。我为什么搭建这个博客，理由我已经忘了，也许是为了炫技？又或者真的想记录知识？翻看我最初的博客，当初我好像只是想记录知识而已。但是不知从何时起，我不爱记录知识了，曾经喜欢探索的心，似乎也随着工作慢慢磨平了。
今年工作上的事，一般，黄神总是push我跳槽，我能感受到他的焦虑，他和我经历有点像，但他学历比我高，我时常安慰他，不要太过焦虑，只是这个社会的原因。但实际上我好像也很焦虑，我不知道在焦虑什么，也许是因为工作，又或者是钱，又或者是其他的事。姚老师总是批评我，内心需要安定一点，我觉得他批评的对，但这也是当代年轻人的现状，姚老师人生洒脱，内心平静，有时候我也羡慕他，他总是反说我也可以，的确，寻找内心的宁静说简单也简单，但说实话很挺难。当我有足够的资金去支撑我的生活吗？未必，那时候又或者有新的想法。
工作上的事我也不想吐槽了，除了老板和值班工作以外都好，有时候忙碌，有时候空闲，不难，说实话有点过于安逸了。这个团队目前问题挺大的，不晓得今年这个团队会咋样，不然又得回去干迁移了，感觉挺没劲的，该准备还是准备起来，给自己留条后路吧。
今年最遗憾的事，还是没能通过软考，一分之差，不过也没啥好遗憾的，也怪自己没好好学习。不过这个失败也让我感觉今年好像没什么技术上的提升。明年看看要不要接着努力吧。
年轻人总是迷茫地过着日子，没错，我也不例外，我至今没找到自己想做的，只是浑浑噩噩混着，好吧，也不算，最起码有些事情也是感兴趣的。新的一年希望能把技术博客重新写起来，回归下本心，静下心来学习学习，顺带看看其他机会。希望新的一年，一切顺利，也祝所有家人朋友能找到属于自己的宁静，身体健康，发大财。

写于2025.12.13，更新于2026.1.8.

又是一年过去，2025年又过去了8个月。去年生日前我也写过一篇文章，那时候离职超两个月，心态有点差，和朋友去外面走了走，聊了聊天，虽然也是苦闷但也不至于特别丧。
十月份过后，我入职了新公司，以全新的起点、全新的挑战去面对没听说过的岗位，那时候还是比较期待的。入职后马上就开始熟悉工作，技术上从云网络入手，逐步扩散到云上的大部分产品，那段时间学习还是比较快的。后面跟随一位大佬做客户迁移工作，现在想想有做的好的地方，也有不好的地方，但总之都顺利完成任务了。

今年4月，组织架构调整，另一个团队合并到我所在的团队，可能老板认为我是比较不错的，因此被他拉着去做另一份他的重点工作。随后便开始接触故障应急、客户稳定性、故障演练等等一些工作，现在回想，也许老板那时候只想多拉点人来干这块吧，很苦，尤其是应急值班，一有大故障那真的要命，不仅如此，有夜班oncalll还睡不踏实，真的非常难受。

今年5月，我开始跟随两位大佬做客户稳定性相关的工作，但说是客户稳定性，但其实我能做的有限，能和客户交流的有限，而且比较有局限性，不是从客户架构的全局视角出发，而是从某个点切入分析问题。负责对客交流架构还是交给另一位大佬讲述，我负责打下手。仔细想想，我也就让客户将业务监控接入了工单系统，有问题可以第一时间排查，也没有特别有亮点的地方。

另一块客户稳定性工作是故障演练，这块我自认为研究的还是比较深入的，当然我指的不是理论方面，而是从实际故障注入的角度来说，包括开源的chaosblade工具，也深入了代码。故障演练这块给几个客户去现场讲述发展与体系，也演示了具体效果，还给一些客户进行了培训。总之这块收获颇丰。

现状

最近有位同事离职了。现在团队可以分为两块业务A和B，后面合并过来的是B业务。他就属于B业务的一员。至于离职原因我认为还是因为和我的老板不对付，并且值班压力大。说实话我挺理解他的，他属于边缘人，现在要求越来越多，他也担心哪天出了问题。但我说实话完全不是事，出问题再说呗，上次心理老师问我，你觉得如果领导责备会对你有什么影响吗？是走人还是说绩效不好？说实话我都不在意。
所以我觉得能过就过吧，而且他属于裸辞，说实话，经历过去年那段时期，我对裸辞还是比较谨慎的。如今工作更难找了，但是我也理解他所处的位置，不走的话更难受。
目前团队现状就是老板过于傻x，整天整细节和微操，他不参活事照样干的顺利。至于我个人成长只能说还行，也有提升但是不接触代码后感觉少了什么，虽然偶尔也会写写脚本，但感觉还是差了点啥。
故障应急值班是真的累，睡不踏实，周末有时候也不敢出门，这是目前最难受的一点。

未来

也和几位大佬聊了一下，不太推荐我在现在这个岗位，技术上还不错，还年轻应该出去多拼拼。其实道理我也都明白，但是总感觉还能带给我什么，除了领导过于傻x以外，并且值班压力大，其他真的也能自由学到很多东西，这也是让我很纠结的一个点。不过今天就是我入职的296天了，马上就一年了，机会还是要多看看，看能否去一个更好的地方。
今年是我27岁，马上就奔3了，一没事业，二没家庭，感觉还是在漂泊，不知道方向何在，但总是默默勉励自己还可以，未来会好起来的。

题外话

之前去上海的那个朋友从大厂离职了，家里人介绍后去了家国企，不得不感叹还是得关系硬啊，可惜家里没权没关系，都得自己拼自己博机会，只是有时候想，这打工何时才是个头啊。

如何设计一个秒杀系统，想必大家一定在互联网上看了各种文章，本文结合内部系统的一些实践还有内部分享，总结了一些系统设计要点，供没有相关经验的同学参考。

什么是秒杀

在电商领域，存在着典型的秒杀业务场景，简单来说就是一件商品的购买人数远远大于这件商品的库存，而且这件商品在很短的时间内就会被抢购一空。即特定SKU的瞬时访问需求呈现指数级增长，而可售库存量级则维持极低水平，最终形成供不应求的”库存击穿”现象。

比如每年的618、双11等业务场景，就是典型的秒杀业务场景。例如2023年双11期间，热门3C单品的每秒订单峰值达12万笔，库存释放后平均3.2秒即告售罄。

秒杀活动的目的是拉新和促活。
拉新：通过实施”锚定商品”策略，选取高认知度、强引流属性的商品设置超低折扣，利用价格敏感型消费者的逐利心理，构建用户转化漏斗。最终形成”流量磁铁”效应。
促活：为主站引流，进而带动高客单价商品的销售。

秒杀的特点

• 业务特点

  • 限时限量限价

  • 活动预热

  • 持续时间短

• 技术特点

  • 瞬时流量突增

  • 读多写少

  • 数据一致性要求高

秒杀系统的挑战

1. 巨大的瞬时流量

作为网站运营体系中的补充性营销手段，秒杀活动具有显著的突发性特征：其业务周期通常以分钟级计算，却在极短时间内会产生指数级增长的并发访问请求。若将此类活动与常规业务系统进行混合部署，将面临双重风险：其一，突发流量可能引发服务器资源过载，导致正常业务响应延迟；其二，更严重的情况下可能造成系统级联故障，致使整体服务平台瘫痪。因此，构建针对瞬时流量洪峰的防御体系，需要从多维度建立系统化的应对策略。

2. 热点问题

在分布式系统架构中，热点问题始终是高并发场景的核心挑战，主要表现为两种形态：操作型热点（如高频接口调用）和数据型热点（如特定商品的库存访问）。对热点的有效识别与治理直接关系到系统稳定性。

• 异常热点请求的资源侵占效应：即使恶意请求仅占全局流量的百万分之一量级，若未建立有效的请求过滤机制，这类无效操作可能占据90%以上的计算资源，形成严重的资源错配现象。这不仅导致基础设施成本的无谓损耗，更会挤压正常业务请求的处理能力。
• 合法热点请求的优化必要性：对于经过验证的有效热点请求，系统架构需要建立分级处理机制。通过热点预判、动态缓存策略、读写分离架构等手段，实现服务资源的精准调度。例如，针对秒杀商品的库存访问，可采用缓存替代传统数据库操作。
• 热点扩散的连锁风险防控：未受控的热点可能引发次生问题，如缓存击穿导致的数据库雪崩，或分布式锁竞争引发的服务阻塞。这要求系统设计时需建立热点监控体系，实现毫秒级的热点识别与动态降级能力。

3. 超卖问题

秒杀开始时，同时会有很多用户请求秒杀接口，如果查询库存和扣减库存这两步操作如果不能保证原子操作。一定会导致超卖问题，造成资损。
如何防止商品超卖造成资损，是需要我们重点考虑的。

4. 接口防刷问题

黄牛党能够利用机器下单、人肉抢单，将秒杀商品瞬间抢到手，然后高价格售出赚取差价。大规模的批量机器下单，还会对网站的流量带来压力，产生类DDOS攻击，甚至能够造成网站瘫痪。
如何防正这类软件的重复无效请求，防止不断发起的请求也是需要我们针对性考虑的。

秒杀系统架构原则

1. 尽量将请求拦截在上游

尽量把请求拦截在上游，逐层过滤减少请求，让请求在秒杀系统可承受范围之内。

我们将请求进行分层，从用户侧到系统分别经过DNS、CDN、WEB网关、WEB服务、中间件、DB。

2. 数据要尽量少

一是用户请求的数据能少就少，包括上传给系统的数据和系统返回给用户的数据。二是要求系统依赖的数据能少就少，包括系统完成某些业务逻辑需要读取和保存的数据，这些数据一般是和后台服务以及数据库打交道的。数据库本身容易成为一个瓶颈，数据越简单、越小则越好。

3. 请求数要尽量少

当用户请求的网页内容完成基础加载后，浏览器的页面渲染流程实际上还会触发一系列次级资源请求。这些被统称为”附加请求”的资源不仅包含基础的CSS样式表和JavaScript脚本文件，还涉及页面中的各类图像素材、异步数据请求（如Ajax技术实现的动态内容加载）等关键元素。

从网页性能优化的角度考虑，应当尽可能压缩这类附加请求的总数量。其根本原因在于每个网络请求的发起都会产生多维度的性能损耗：首先在连接建立阶段需要完成完整的TCP三次握手协议，若涉及HTTPS加密通信还会增加TLS协商的额外开销；其次，受限于浏览器对同域名并发请求数的限制（通常为6-8个），以及部分资源（特别是JavaScript脚本）因可能修改DOM结构而必须采用的串行加载机制，请求队列的堆积会显著延长关键渲染路径；再者，当资源分布在多个不同域名时（如使用CDN加速或第三方服务），每个新域名都需要经历完整的DNS解析过程，包括递归查询、缓存验证等环节，这在网络状况欠佳时可能产生数百毫秒级的延迟。

因此，通过减少附加请求总量，可以有效规避上述各环节的潜在性能瓶颈，从而显著降低网络传输开销、提升资源加载效率，并最终改善终端用户的体验感知。

4. 请求路径要尽量短

请求路径特指客户端请求从发起到最终数据返回所经历的系统节点拓扑。从接入层网关到业务逻辑服务，再到数据库集群，每个节点都会引入特定处理时延。缩短调用链路不仅能提升系统可用性（减少单点故障概率），更能产生双重性能增益：其一降低序列化开销（每经过一个RPC节点至少触发两次编解码操作，常见协议如JSON序列化的CPU耗时可达毫秒级），其二压缩网络传输时间（跨机房调用通常产生5-15ms额外延迟）。

典型优化策略包括但不限于：对业务强耦合的服务实施”物理部署聚合”，通过JVM内方法调用替代跨进程通信，此举可消除协议转换开销（如Dubbo协议头128字节的无效负载）

5. 依赖要尽量少

系统依赖可划分为强依赖（服务不可降级）与弱依赖（具备柔性处理能力）两类，其中强依赖构成系统稳定性关键路径。科学的依赖治理需建立三维管控体系：首先实施”服务分级认证”，构建0-3级金字塔型架构（0级：直接影响核心交易链路；1级：重要业务支撑系统；2级：非关键业务系统；3级：辅助型系统），并遵循”同级或向下兼容”原则——0级系统仅允许依赖同级或更高级服务；其次建立”熔断防护机制”，通过Hystrix等框架实现故障服务的快速隔离，当1级依赖系统（如优惠券服务）响应成功率低于阈值时，自动触发服务降级并返回托底数据；最后采用”异步化改造”，将非必要同步依赖转换为消息队列驱动的异步处理模式。以支付系统为例，其作为0级系统对接的风控服务应保持同级，而日志采集等辅助功能需通过Kafka异步解耦，确保核心链路不受边缘服务故障影响。

系统设计

DNS处理

DNS 层可以做一些和网络相关的防攻击措施，例如CNAME-WAF，这层我们无法写业务，但是可以拦截一些攻击请求。

前端设计

前端页面动静分离

动静分离的首要目的是将动态页面改造成适合缓存的静态页面。这个如今的新系统大多数都能采用这种设计。下面我来介绍几种常用的手段。

数据拆分

• 用户：用户身份信息包括登录状态以及登录画像等，相关要素可以单独拆分出来，通过动态请求进行获取；与之相关的广告推荐，如用户偏好、地域偏好等，同样可以通过异步方式进行加载。
• 时间：秒杀时间是由服务端统一管控的，可以通过动态请求进行获取

数据静态缓存

三种方式：1、浏览器；2、CDN；3、服务端。这个没什么好说的，都是基础了。

数据整合

这里介绍两种方案。

• ESI方案：Web代理服务器上请求动态数据，并将动态数据插入到静态页面中，用户看到页面时已经是一个完整的页面。这种方式对服务端性能要求高，但用户体验较好
• CSI方案：Web代理服务器上只返回静态页面，前端单独发起一个异步JS请求动态数据。这种方式对服务端性能友好，但用户体验稍差。

接口url动态化

为了避免有程序访问经验的人通过下单页面直接访问秒杀后台接口来秒杀货品，我们需要将秒杀的url实现动态化，即使是开发整个系统的人都无法在秒杀开始前知道秒杀的url。具体的做法就是通过hash一串随机字符作为秒杀的url，然后前端访问后台获取具体的url，后台校验通过之后才可以继续秒杀。

前端页面拦截处理

在用户点击秒杀按钮之后，可以先进行用户行为判断，这样可以拦截掉很多刷接口的秒杀器。

验证码、拼图、答题方式

在发起秒杀后端请求之前，先进行验证码、拼图、答题判断，验证成功才可以继续后续流程。

限制请求频次方式

限制用户点击秒杀按钮的频率，强制用户等待。这属于前端限流，用户在秒杀按钮点击以后发起请求，那么在接下来的5秒是无法点击(通过设置按钮为disable)。这一小举措开发起来成本很小，但是很有效。

接入风控

对于秒杀器等机器秒杀行为，需要在上游做拦截处理，防止它们超高频的请求对秒杀系统造成巨大的流量压力。秒杀系统需要接入营销风控系统，对羊毛党、黄牛党等营销作弊行为进行风险监控、预警、识别、过滤、阻断。这样秒杀系统的压力就转移到风控系统了，减少了自身压力。

服务端设计

秒杀系统高可用设计，有隔离、削峰限流、缓存热点处理、熔断降级、扩容等一系列措施。

隔离设计

通过秒杀流量的隔离，我们能够把巨大瞬时流量的影响范围控制在隔离的秒杀环境里。

• 业务隔离：把秒杀做成一种营销活动，卖家要参加秒杀这种营销活动需要单独报名，从技术上来说，卖家报名后对我们来说就有了已知热点，因此可以提前做好预热。
• 系统隔离：系统隔离更多的是运行时的隔离，可以通过分组部署的方式和另外99%分开。秒杀可以申请单独的域名，目的也是让请求落到不同的集群中。
• 数据隔离：秒杀所调用的数据大部分都是热点数据，比如会启用单独的Cache集群或者MySQL数据库来放热点数据，目的也是不想0.01%的数据有机会影响99.99%数据。

削峰限流

限流是一种有损技术削峰。
验证码、拼图、答题以及异步化消息队列可以归为无损削峰。

限流

限流是系统自我保护的最直接手段，再厉害的系统，总有所能承载的能力上限，一旦流量突破这个上限，就会引起实例宕机，进而发生系统雪崩，带来灾难性后果。
可以使用Sentinel、Hystrix、Ratelimiter等做限流。

削峰

产品方式的削峰：验证码、拼图、答题。

技术方式的削峰：异步化消息队列。

热点处理

热点数据分为“静态热点数据”和“动态热点数据”。

静态热点数据是能够提前预测的热点数据例如，我们可以通过卖家报名的方式提前筛选出来，通过报名系统对这些热点商品进行打标。另外，我们还可以通过大数据分析来提前发现热点商品，比如我们分析历史成交记录用户的购物车记录，来发现哪些商品可能更热门、更好卖，这些都是可以提前分析出来的热点。

动态热点数据不能被提前预测到的，系统在运行过程中临时产生的热点例如，卖家在抖音上做了广告，然后商品一下就火了，导致它在短时间内被大量购买。缓存热点数据

优化热点数据最有效的办法就是缓存热点数据，如果热点数据做了动静分离，那么可以长期缓存静态数据。但是，缓存热点数据更多的是“临时”缓存，即不管是静态数据还是动态数据，都用业个队列短暂地缓存数秒钟，由于队列长度有限，可以采用LRU淘汰算法替换。

限制热点数据

限制更多的是一种保护机制，限制的办法也有很多，例如对被访问商品的ID做一致性Hash，然后根据Hash做分桶，每个分桶设置一个处理队列，这样可以把热点商品限制在一个请求队列里，防止因某些热点商品占用太多的服务器资源，而使其他请求始终得不到服务器的处理资源。

限购

限购之于库存，就像秒杀之于下单，前者都是后者的过滤网和保护伞。
限购的主要功能就是做商品的限制性购买，一般限制的维度主要包括两方面。

商品维度限购

最基本的限制就是商品活动库存的限制，即每次参加秒杀活动的商品投放量。如果再细分，还可以支持针对不同地区做投放的场景，比如我只想在北京、上海、广州、深圳这些一线城市投放，那么就只有收货地址是这些城市的用户才能参与抢购，而且各地区库存量是隔离的，互不影响。

个人维度限购

以个人维度来做限制，这里不单单指同一用户ID，还会从同一手机号、同一收货地址、同一设备IP等维度来做限制。比如限制同一手机号每天只能下1单，每单只能购买1件，并且一个月内只能购买2件等。个人维度的限购，体现了秒杀的公平性。

减库存

减库存一般有三种方式：下单减库存，付款减库存，预扣库存。

而秒杀这个场景，应该采用哪种方案比较好呢？

由于参加秒杀的商品，一般都是“抢到就是赚到”，所以成功下单后却不付款的情况比较少，再加上卖家对秒杀商品的库存有严格限制，所以秒杀商品采用“下单减库存”更加合理。
库存超卖的问题主要是由两个原因引起的，一个是查询和扣减不是原子操作，另一个是并发请求无序。

库存不能扣减为负数

要保证大并发请求时库存数据不能扣减为负数，有以下几个方案：

• 在应用程序中通过事务来判断，即保证减后库存不能为负数，否则就回滚
• 直接设置数据库的字段数据为无符号整数，这样减后库存字段值小于零时会直接执行SQL语句来报错
• 使用CASE WHEN判断语句，例如这样的SQL语句：
  UPDATE item SET inventory = CASE WHEN inventory >= xxx THEN inventory-xxx ELSE inventory END

缓存中减库存

秒杀商品的减库存逻辑非常单一，比如没有复杂的SKU库存和总库存这种联动关系的，可以把秒杀商品减库存直接放到缓存系统中实现，也就是直接在缓存中减库存。

数据库中减库存

如果有比较复杂的减库存逻辑，或者需要使用事务，还是必须在数据库中完成减库存。由于 MySQL存储数据的特点，同一数据在数据库里肯定是一行存储（MySQL），因此会有大量线程来竞争InnoDB行锁，而并发度越高时等待线程会越多，TPS会下降，响应时间（RT）会上升，数据库的吞吐量就会严重受影响。

解决并发锁的问题，有两种办法：

• 应用层做排队: 按照商品维度设置队列顺序执行，这样能减少同一台机器对数据库同一行记录进行操作的并发度，同时也能控制单个商品占用数据库连接的数量，防止热点商品占用太多的数据库连接。
• 数据库层做排队: 应用层只能做到单机的排队，但是应用机器数本身很多，这种排队方式控制并发的能力仍然有限，所以如果能在数据库层做全局排队是最理想的。阿里的数据库团队开发了针对这种MySQL的InnoDB层上的补丁程序(patch），可以在数据库层上对单行记录做到并发排队。

总结

秒杀系统的设计本质是一场高并发场景下的“攻防战”，既要保障极致的性能与稳定性，又要兼顾业务公平性与数据一致性。本文从秒杀的业务与技术特点出发，系统性地梳理了四大核心挑战——瞬时流量、热点问题、超卖风险与接口防刷，并提出了五大架构原则：请求拦截上游化、数据精简、请求收敛、链路缩短、依赖解耦。

在系统设计层面，通过动静分离、动态URL、前端拦截与风控接入，将无效请求层层过滤；借助业务隔离、削峰限流、热点缓存与预扣库存策略，精准控制核心资源；最终结合异步队列、分布式锁与原子化操作，保障库存与交易的最终一致性。

秒杀系统的设计没有“银弹”，需根据业务规模动态权衡技术方案。但核心逻辑始终不变：化瞬时洪峰为涓涓细流，以最小代价支撑最大并发。希望本文总结的实践经验，能为初涉高并发系统设计的开发者提供清晰的解题思路，在面对类似场景时，快速构建出可靠、弹性、高效的秒杀架构。

本文详细阐述某企业遗留系统云端迁移的技术实现过程，文中不涉及敏感信息与可视化资料，仅作技术方案参考。

背景

某企业客户部署的n台经典网络实例需实施跨可用区迁移，客户技术团队在2024年度三次自主迁移尝试均告失败。该业务系统自201x年上线以来累计服务千万级活跃用户，每周三至周日高峰时段并发用户达数十万量级。系统架构包含18台ECS+x个RDS-MySQL+x个Redis+x个MongoDB+x个RabbitMQ的复杂组合。

由于系统历经多次技术团队更迭，现存系统存在三大核心痛点：

1. 源代码及部署文档遗失
2. 服务调用关系不明晰
3. 关键组件单点部署风险
   日常运维仅能维持基础功能运行（曾出现服务器重启导致部分业务模块失效的情况）。客户原定2025年2月启动系统重构计划，但因业务连续性要求无法等待，故紧急启动迁移项目。在获得有限权限（控制台只读账号+OS级访问）后，技术团队通过逆向工程完成架构梳理并制定迁移方案。

网络拓扑现状

现网环境分析

客户现有两个VPC网络：

• 业务VPC：172.16.0.0/16
• 迁移专用VPC：10.0.0.0/8
  三台经典网络实例（10.25.63.135、10.27.10.158、10.29.112.12）需保持与业务VPC互通。

技术障碍突破

检测发现存在Classlink配置冲突问题：若保留经典网络连接通道，将导致其他ECS无法通过迁移计划进行迁移，影响迁移前后服务的互通。通过为期7天的流量捕获分析：

• 2台实例无业务流量交互
• 1台实例仅存在TCP握手空连接
  进一步端口扫描确认该流量源于业务VPC访问废弃Nginx端口，故所有Classlink均可安全拆除。

业务系统剖析

服务组成

• Windows集群（4节点）：具备完整文档，独立迁移
• Linux集群（14节点）：承载核心业务，无部署文档

技术栈特征

• 应用层：SpringBoot+SpringCloud单体架构，无CI/CD流程
• 中间件：自建ZK集群+单节点Memcache/MySQL/Nginx/Apollo
• 云服务：混合使用RDS/Redis等托管服务
• 历史债务：大量硬编码数据库连接（IP/域名）、公网IP监听等技术债

迁移实践

采用分批次渐进式迁移策略，每周一二低峰时段迁移2-3台实例，整体方案分为网络重构、数据库迁移、应用迁移三阶段实施。

网络架构改造

1. 解除无效Classlink连接
2. 创建跨VPC对等连接满足跳板机需求
3. 在迁移VPC中规划与原有ECS网段不重叠的24位子网
4. 将业务VPC与迁移VPC的路由配置完成。

数据库迁移

经典网络数据库迁移至VPC网络的实施流程主要包含两个核心环节，每个环节均需通过控制台可视化操作完成且业务无感。具体实施规范如下：

1.安全组变更。

执行安全组规则分离操作，实现经典网络与VPC网络的白名单隔离管理。系统会自动将原经典网络已授权的IP地址段同步至VPC白名单策略组。特别建议在VPC白名单中预置10.0.0.0/8全量地址段，该配置前瞻性解决后续网络架构中网络负载均衡（NLB）组件采用FULLNAT模式时，可能因源地址转换导致真实客户端IP被过滤的问题，确保业务流量无阻断风险。

2.开启临时混访。

网络类型切换时需勾选”保留经典网络地址”选项，该操作将生成专属于VPC网络的访问终端节点，形成经典网络与VPC网络双地址并存的混合访问模式。若未保留经典地址，将直接导致未迁移业务系统失联。

网络切换完成后，需选取任意业务ECS实例执行网络诊断：分别对经典网络连接地址和VPC连接地址执行dig命令解析，完整记录两个终端对应的实际IP地址。此操作获取的IP映射关系，为后续解决应用程序硬编码连接地址的改造工作提供基础数据支撑，确保业务平滑迁移过渡。

1
2
3
4

dig classic-db.example.com +short
10.141.20.223
dig vpc-db.example.com +short
10.1.0.79

应用迁移攻坚

ECS迁移应用上发现有3个已知问题，分别为写死固定字符串连接、写死数据库固定IP、写死公网IP监听，针对这3个问题分别制定了3种应对策略，在ECS迁移启动后首先完成这3类问题处理，然后再进行后续程序启动

技术债务应对方案

1.域名硬编码连接优化

问题特征：应用程序采用硬编码数据库域名连接方式，但实际存在不可变连接字符串约束

技术方案：

1. 建立全网域名-IP映射表：系统化梳理所有RDS实例的经典网络域名与专有网络IP对应关系
2. 实施本地DNS覆盖：通过修改ECS实例的/etc/hosts文件，建立”经典域名→专有IP”的静态解析规则，保持应用层代码零改造
3. 设计过渡期运维机制：针对数据库跨可用区迁移导致的IP变更风险，建立人工巡检与hosts文件更新流程。同步规划系统重构计划，要求新建ECS必须采用动态域名解析标准方案

1
2

经典架构：应用代码-> 经典域名 -> 经典IP(10.172.X.X)
过渡架构：应用代码-> 经典域名 -> hosts解析 -> 专有IP(10.X.X.X)

2.IP直连架构改造

问题特征：应用程序直接硬编码数据库IP地址，无法通过常规DNS方案解决

创新方案：

1. 构建NLB代理层：通过OpenAPI创建指定保留IP的NLB实例，严格保持原应用配置的IP地址不变
2. 配置透明转发规则：建立NLB监听器与RDS专有网络IP的绑定关系，白名单放通NLB固定出口IP
3. 实现流量无损切换：业务流量经NLB全量转发至新数据库节点，网络拓扑变更对应用完全透明

1
2

传统架构：ECS -> RDS(10.172.X.X)
迁移架构：ECS -> NLB(10.172.X.X) -> RDS(10.X.X.X)

3. 公网IP绑定重构

问题特征：应用代码写死监听公网IP地址，在ECS迁移到VPC网络后，eth1公网网卡将会被删除，原公网IP将映射到内网eth0网卡，不在直接在系统内显示。应用不能监听公网IP，需要修改为监听内网IP。目前应用已不具备能力修改，需要使用其他方案解决此问题。

改造方案：

1. 公网IP弹性化改造：将原有固定公网IP转换为弹性公网IP(EIP)
2. 辅助网卡部署：为ECS挂载第二块虚拟网卡，采用”EIP直通绑定”模式实现公网IP可视化
3. 智能路由配置：精细化定义双网卡路由策略
   • eth0(主网卡)：承载10.0.0.0/8及172.16.0.0/16内网流量
   • eth1(辅助网卡)：配置默认路由，处理公网出入流量

4.应用启动

实施规范：

1. 分级启动机制：
   • 基础层：优先启动Nginx、Redis等开源中间件，完成健康状态校验
   • 支撑层：依次启动基础服务、核心组件、API网关
   • 业务层：最终启动控制台等前端服务
2. 立体化排障体系：
   • 有日志服务：实时监控error级别日志，结合代码反编译精准定位异常
   • 无日志服务：采用tcpdump抓包分析+strace系统调用追踪的复合诊断模式
   • 业务验证：完整执行核心功能测试用例，数据一致性校验通过率需达100%
3. 观测期管理：
   • 建立3小时黄金观察期，监控QPS、错误率、响应延时等12项核心指标
   • 配置业务流量灰度放量机制，按10%、30%、50%、100%阶梯递增
   • 达成零客户投诉且系统指标平稳运行后，方可启动下一节点迁移

总结

本次迁移不仅完成基础设施升级，更帮助客户重建了系统架构图谱。项目结束后，客户技术团队已着手推进以下改进：

• 建立配置管理中心
• 实施CICD流水线
• 构建双活容灾架构

此次实践验证了对传统系统改造的技术可行性，为同类项目提供了有价值的参考范式。

2024年又是弹指一挥间，当我回看23年的总结时，总是还觉得还在昨天。去年在总结中写到今年的展望，说到今年想换个环境继续提升自己，完成了一半的目标吧，环境换了，但是提升打个问号。提笔忘字，每当到了要写点什么时，都不知道怎么去描写现在的心情和想法。

正文

站在26岁的十字路口，我也开始思考之后的道路。

一季度

一月份我记得很清楚的很清楚的一件事就是签了器官捐赠，也是受到一个游戏的影响，为社会做点贡献。同样在一月还获得了绝区零的内测资格，大概体验了一下，不是特别对胃口，也提了一些意见与建议，最后给了几十块钱酬劳好像哈哈哈。公测之后玩了一个版本后就放弃了。

二月份的时候去了趟上海，参加崩三的活动，去南京路还有黄浦江边走了走，当天回程时还差点买不到票。然后就是春节，回了老家，不得不说老家的旅游业越办越好了。春节期间还拜访了老师，和朋友聚了餐，放假总是时间飞快。

三月份去办理了护照，但是后面还是没有办理签证，出趟国太费钱也太累了，最终还是选择不去。然后和大学舍友约了个饭，聊了聊之后的规划，以及目前的环境，其实从那时候开始就打算要离职了。约饭那天周五，还有人打电话给我，虽然我没接，但是种子已经埋下了。

二季度

四月份开始自己做饭了，买了柴米油盐，还有锅刀啥的，第一顿做的是西红柿炒蛋加火腿肠，结果太咸了哈哈哈。二季度一开始领导要开始搞内部框架大统一，说实话我觉得不现实，但是上头要求就得做，底下的人苦不堪言。四月底的时候和领导聊了聊，表达了自己会离职的想法，领导让我好好考虑考虑，也不断的和我沟通，毕竟合格的牛马不能轻易放走。

五月份的劳动节假期听了星铁的演唱会，并且去线下的星铁land活动，但我个人不喜欢coser，因此大多数时间都在看场景和节目。五月中旬我便不参与开发和评审任务了，那段时间真的特别轻松，想着离职后的规划，觉得后续会好起来的。这段时间也看了一些机会，但是没有去投递。

同时，我还去尝试了正骨复位、针灸、拔罐，去治疗我的颈椎，这几天又不好了，肯定是上班上的。

六月初，我的离职日到了，那天早上我还在和用户沟通，记忆尤新，下午的时候和其他组的领导聊了聊，反馈了目前大组里的现状。结束后去办理了离职手续，和组里的同事告别之后，焕哥正好说要送我一程，开着车请我吃了顿饭。那天真的五味杂陈，既有离职的兴奋，又有对未来的迷茫，还有对遇到一群这么好的导师、领导、同事而我却离开的惋惜。

离职之后几天，开始请之前的几个比较好的同事吃饭，聊了很多，但更多的是对康子的吐槽，还有对未来的迷茫。

随后我便开始休整，不紧不慢的修改简历，六月中下旬开始投递，第一个挂我的是好像是字节，后面六月份好像挂了两三家，那时候觉得还行，积累经验。熟不知后续经历让我更加迷茫。

在我离职后不久，还有几个同事陆续离职，也许是受不了当前的环境，也许是受够了日夜的加班，我也祝福他们能找到自己的路。

三季度

七月份开始，我便开始高强度的找工作，上午起床学习，下午面试，晚上复盘加修改简历，但全都了无音讯，这时候其实我有点慌了，我没想到同事口中很强的我竟然一个offer全都没有，尽管面试不断，但全都没有得到反馈。

八月份，得知一个四月份离职的同事找到了一份不错的工作，我既高兴也不解，他和我住附近，有时候还会帮他喂猫咪。他选择离开杭州前往上海，但令我不解的是平常感觉一般的他却能上岸不错的工作，使我非常疑惑，但我也祝福他。随后又开始了一波新的面试，但依旧草草收场。

八月中旬，为了缓解苦闷，我去了上海参加了原神的嘉年华，特意买的还是vip票，当我检票的时候已经十点多了估计，vip检票口一个人都没有，那个小哥还问我游戏多少级了哈哈哈。

八月下旬开始看软考相关的东西，但是也是属于三天打鱼两天晒网，每天就看一点，也没有看的多么仔细。

随后九月到了自己的生日，买了蛋糕当了晚饭。那天和帅哥他们出来逛了湘湖，并在那天喝了一杯伏特加，第一次喝酒头晕，那天洗完澡后马上就睡着了。

九月还去了西溪湿地逛了逛，剩下时间基本都是学习、面试、打游戏。那段时间自己确实比较焦虑，因为离职后面试三个月了一点反馈都没有，自己的自信心有点受到打击了。

九月底和林子哥他们去了崩三联动的肯德基，吃了联动套餐，又拿了一堆周边回来。同时离职的事老妈也知道了，但她没有催我去找工作，二是让我国庆回家休息休息，没钱了可以和她说。父母永远是自己后盾这句话真的难以言表，真的感谢父母。

四季度

十月份国庆回了趟老家，老家的房子终于快装修好了，调整了家里的网络，拍了拍照片，帮忙进行了一些收尾。国庆结束后尽管老妈让我多呆几天，但是因为自己拉不下面子，没回来杭州的话估计别人就知道没工作了，总之还是回来了。

国庆后有好消息就是有两个offer，但是一个是od直接pass了，最后选择了目前这边。确认offer之后便开始玩游戏了，早上做点软考题目，下午和晚上玩游戏打炉石，当然面试也同步在进行。

十一月份，准备搬家，从萧山搬到西湖区，我的物品已经一辆小面装不下了，下次搬家得约中面才行了。同时医保被冻结，看病得花自己钱，肉疼。

十一月中旬，开始上班。阿里云这边确实不是很卷，但是有时候需要回个消息，开始了解云上网络原理、架构，但说实话接触不到底层实现。

月底去了植物园逛了逛，用现金买了实体票，和林子哥帅哥卿哥吃了个饭，深夜食堂，味道还不错。

十二月，也基本都在忙工作的事，有时候周末也得加加班，也逐渐了另外两个同事熟悉了，会聊一些其他话题。他们说康子太苦了，加班到凌晨还没有调休，我也只能哈哈一笑。来了两周的同事今年的最后一天离职了，他觉得学不到什么去了一家初创公司，先不论他的决定是否正确，但我也尊重他的选择，祝他前程似锦。

后记

赶在零点前写到这里，好久没用机械键盘打这么字，打的我手腕疼。

站在26岁的十字路口，也开始思考之后的道路。每次看到朋友圈结婚的，当官的，当老师放假的，我便不禁思考我未来的道路，仍然一片迷茫。我想做的东西究竟是什么，经过今年五个月没工作时间的思考，我又再次迷茫。另一方面，我钱也不多，三年的康子工作我并没有攒下多少钱，甚至不足以我去继续深造。随着年龄的增大，我是否还有机会改变目前的现状仍是未知数。但另一方面也不能完全相信出国读了书回来能remake重生，未来的事真的说不准。

另外目前这边的工作主要是技术上提升较小，全都得靠自己摸索学习，尽管大佬很多，但帮助有限。明年的我是否会另外寻找工作目前也还是未知数，但如果工作内容持续是这样的话，那么我估计离职也不远了。

希望明年的我运气能好点，不仅是找工作，各种方面都希望能好起来。另外也希望自己和家人能健健康康活着，我觉得这才是最关键的事情。永远健康，永远开心，后面才是考虑其他的。

加油吧，未来的我，今年的我只能到这里了，也感谢今年的我，确实努力过了，奈何运气差一些。相信明年都会好起来的。

昨天睡前突发奇想，想着要不设计什么系统来思考思考，正好前段时间看到一篇关于站内信的设计文章，里面也有不少可以琢磨的。但是又没想法要设计啥系统，便在各个游戏里琢磨，想着o神这个邮件系统应该也有不少思考，因此决定设计一个游戏邮件系统。注意这个游戏的邮件系统只针对管理员向用户发送的邮件系统，用户间不存在邮件交互。

在这里也先叠个甲，本人非游戏从业中，只是从一个后端开发，架构师的角度去思考这个问题，结合业务的话我也只能进行一定猜测，本文的所编写的任何东西不构成生产建议或实践！欢迎友好交流的同学一起讨论和学习。

正文

需求明确

首先我们需要明确设计的目标，我列了以下几个点，当然还有一些没有罗列，我们就按照简单的需求来设计。

• 管理员(运营)可以向用户发送邮件。
• 收到的邮件主体包括标题，接收时间，发送人，正文，附件。
• 用户间不可以相互发送邮件。
• 运营可以根据用户条件并且指定时间发送邮件。
• 用户接收群发邮件时接收时间可以为上线时间或者运营确定的时间。
• 邮件可以有过期时间，到达过期时间后，邮件将被删除。

需求还是比较简单并且清晰的。

其中值得一提的是，最后一个点我认为是出于性能的考虑，可以防止大量的数据同时写入。也可以排除掉不活跃的用户。

其他的一些需求，比如收藏邮件，其实和主体并没有什么冲突，只需要加字段即可实现。

接下来就讲讲具体的设计思路。

设计思路

说是设计，其实这个系统只要把字段逻辑理清楚，尤其是数据如何存储，比如分表如何分，字段设计完成后，其他如上层开发就简单一些。

字段设计

我一直觉得实体类设计是比较简单的一环，尤其是当业务清楚的时候。

先给出第一版设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125

@Data
public class Attachment {

    private Long itemId;

    private Integer num;
}



@Data
public class SystemEmail {

    private Long id;

    private String sender;

    /**
     * 标题
     */
    private String subject;

    /**
     * 是否为确定的接收时间
     * true 用户邮件的接收时间为系统邮件指定的时间
     * false 用户邮件的接收时间为拉取系统邮件的时间
     */
    private Boolean timeExacted;

    /**
     * 接收时间
     */
    private LocalDateTime receivedTime;
    /**
     * 主体
     */
    private String content;

    /**
     * 附件列表
     */
    private List<Attachment> attachments;

    /**
     * 邮件过期时间
     */
    private LocalDateTime expiredTime;

    /**
     * 用户id列表
     * 当用户id在列表中时，可以拉取
     * 否则需要检测条件是否满足
     */
    private List<Long> uidList;

    /**
     * 邮件发送条件
     */
    private List<String> conditions;
    
    
    private LocalDateTime createTime;
    
    private Long createUserId;
    
     /**
     * 是否删除
     */
    private Integer deleted;
}


@Data
public class UserEmail {
    /**
     * The Id.
     */
    private Long id;

    /**
     * 用户id
     */
    private Long uid;
    /**
     * 发送人
     */
    private String sender;
    /**
     * 标题
     */
    private String subject;
    /**
     * 接收时间
     */
    private LocalDateTime receivedTime;
    /**
     * 主体
     */
    private String content;

    /**
     * 附件列表
     */
    private List<Attachment> attachments;
    
     /**
     * 邮件过期时间
     */
    private LocalDateTime expiredTime;

    /**
     * 系统邮件来源
     */
    private Long systemEmailId;

    /**
     * 记录创建时间
     */
    private LocalDateTime createTime;
    
     /**
     * 是否删除
     */
    private Integer deleted;
}

这里先谈谈我的设计思路。

首先所有的邮件是由系统去创建的，并且在数据库存储上，不可能是系统发送邮件后就对所有用户写入邮件数据，所以必然应该有一张或者多张表存储系统邮件信息，然后再根据一个触发条件（一般是登录）去将系统邮件的内容写入到个人邮件数据中。因此用户邮件UserEmail和系统邮件SystemEmail应该有一个关联id。

此外系统邮件应该有个字段自由控制接收时间，这里我命名的是timeExacted，意思是时间是否确定。

那其实数据结构字段就差不多了。

数据表设计

既然实体类已经设计完成，那其实表的设计就按照实体类即可，但是其实还需要考虑挺多点。

首先，老生常谈的问题，分库分表。当然，对于这个系统而言，我们可以只考虑分表的情况，底层的性能我们可以先不考虑，先从业务上进行分表的设计。

分库分表

为什么要分表？防止单表的数据量达到一定量级总而造成性能问题。首先用户邮件的设计上，我们采用uid字段去进行区分，对于单表来说只需要简单的sql查询即可完成个人邮件检索。

1

select * from t_user_email where uid = 1000 order by receviedTime desc;

但是考虑到用户的量级上，假设一个服务器上有1亿个活跃账号，每个账号有100封邮件，那么此时用户邮件表中就有100亿条数据，这个量级是十分恐怖的。尽管有邮件过期机制，但是长时间运营的游戏必然会有很多永久邮件存储在用户上。

因此必须要分表。那么怎么分呢？以阿里的规范来说，单表超过500w条记录或者2GB时，才进行分库分表，我们先以这个标准去进行分表，假设单表500w，100亿条数据我让AI回答了一下，它说需要2000个表才可以存的下。那我们就以两倍进行预估，那么就需要分4000个表。

假设mysql能抗住这么大的一个并发，那也得分4000个表去存储，一般情况下是根据uid进行hash取模，然后落到不同的表上。

但实际情况下，单库分4000个表是不现实的，因为单库根本扛不住这么多的流量，这就有点脱裤子放屁了。所以应该是先分库然后再分表，这里的4000最接近4096，因此可以先进行模64分库，然后用相同字段div 64后模64进行分表，这样会稍微合理一些。

但随着时代的变迁，分库分表会将成为历史。据我所知，马哈鱼的游戏基本上都是用的阿里的PolarDB分布式数据库，无需去关心分库分表。

系统设计

这个主要就是业务上的一些实现了，如果说不再考虑分库分表的话，其实业务系统上的就比较简单了。向用户发送邮件的流程应该如下

1. 运营向系统邮件表写入邮件内容。写入完成后，邮件系统发送通知到主进程。
2. 一些内部流转邮件，例如签到奖励，可以直接写入用户邮件表中。
3. 用户此时正在游戏中，主系统收到用户邮件通知，或者登陆进游戏后触发邮件拉取检查。
4. 此时邮件系统将系统邮件写入用户邮件表。用户收到邮件到达通知。
5. 用户收到邮件。
6. 阅读和领取操作。

其中有个比较关键的点就是邮件拉取。比如拉取的时间范围应该是什么？如何去判断是否已经拉取过？

首先拉取范围，应该是用户上次登录时间到此时的所有邮件。当然邮件有过期时间，可以加上条件过滤掉，其实不会有那么多。

是否拉取过那就很简单了，判断systemEmailId是否有就好了。

总结

写到这里其实逻辑差不多清楚了，但是我没有选择去实现这个。业务上的逻辑其实还是得深入研究。本文主要还是从表的设计入手去分析如何实现。顺带讲了讲分库分表的事，虽然我认为它一定会退出历史舞台。

当然也还有很多东西没讲到，比如过期删除的逻辑，条件判断逻辑等等。

其实有些东西只有当你确确实实要去用代码去实现时才能发现问题所在。

说实话写到后面其实自己差不多已经倦了，所以打算结束这篇思考。花了两三天陆陆续续完成这篇文章。总的来说还是思考了不少东西，但也让我意识到自己可能对于代码实现不是那么有激情了，也许是年纪大了。

后面应该就去新公司那边了，看看能不能学习到一些新的东西。

现在是10月中旬，距离我上次写文章已经过去一个多月了，时间太快了。

这一个月我都干了些啥呢？整个9月份我就面试了诚云和菜鸟两家公司，诚云面试了4面，加上8月份还面了2面，一共有6面，虽然中途换过部门。菜鸟国庆前两面，国庆后一面。

至于结果嘛，诚云是面试通过了但是没有HC，一直就挂着。菜鸟的话大概率HR面寄了，我说离职原因是学不到东西，但是HR说做这么多东西和学不到东西是冲突的，她觉得很矛盾。我也觉得她说话很矛盾，她不理解我，我不理解她。

细想下来，好像9月份做的事情很少，还有的话就是看了看软考视频，感觉也没认真学下去。

9月10月又是中秋又是国庆，所以也浪费了不少时间，不管是面试的还是个人的。

还有就是9月份老妈知道我离职了，她也说慢慢找，没有钱可以和她说，和我爸说的一样，父母还是关心孩子的，希望儿女不要有那么大的压力。

国庆久违的回了一次家，10天，一点东西都没学，都在陪老妈收拾东西搬家，看电视。有时候觉得这种日子也挺不错的，但我知道总是要工作的，在国庆假期后第一天我就回杭州了。

接下来我也不知道咋办了，焦虑焦虑还是焦虑，打开招聘软件焦虑，因为感觉没有合适的岗位，睡觉焦虑，因为想着面试经历还有后面的不确定性。

但是面试还得继续，我实在不想去OD，不管菜鸟有没有offer，虽然十月过半，但也要继续修改投递简历面试，人生还是要积极。

好在虽然股市亏损了，但是没投入多少，还在可控范围内。存款也还有不少，最起码在杭州一年半载是没啥问题的。

继续加油吧。

后话

昨天玩了一部游戏，感觉对相亲也没那么排斥了，但是说实话我遇不到那么好的女生(哭)，到头来只是宅男的幻想罢了。但是游戏里有些观点我还是比较认同的，比如恋爱观，相处观等等。其实我还是对自己未来的不确定性而担忧，没法承担另一个人的责任，主观上一直在抗拒。但也有人和我说应该两个人相互扶持，我也认同，但这个社会过于浮躁了，并且对于男方太过于苛责，渣男渣女太多，导致很多人不敢恋爱。哈哈哈，总之不知道什么时候才能遇到自己喜欢的另一半呢。

今天是8月最后一天，总觉得我应该写点什么，但是提笔忘字，哦不对，应该说手放键盘，却不知写下何物。

今天早上五点半起床去爬了山，结果下山的时候低血糖，还好山不是很高，救回一条狗命。

又去浙大玉泉校区看了看，可望不可即的感觉，门口有来送孩子上学的父母，她父母应该为他们的女儿或者儿子感到骄傲吧。高考真的是决定人的一生，我确实感觉到了，很多单位招聘只看第一学历，因为不管研究生或者留学生，其实钱能到位就好说，因此他们只相信相对公平的高考，相信被高考录取的学校就是你的实力。说实话，我打心里不认同，因为我认识第一学历一般，但是凭借自己努力考上研究生或者入职某个好单位的朋友，但是在这个社会上又不得不唯第一学历论，感觉很悲哀。

上周末把boss上的简历给隐藏了，这周没有消息来打扰了。这周面试了华为od的流程，包括两面技术面，一面主管面。周三的时候阿里云的技术服务经理岗也面了一面，不过感觉是刷KPI的，应该不太行。

华为od应该是八九不离十可以给offer的，整体面试难度偏低，说实话，只要你是目标院校，并且有点基础，代码也还可以，那么轻轻松松，没有网上说的那么难。又回到了上面说的学校论了，不过od看的是你的最高学历，目标院校笔试只要150，而听说非目标需要300往上。

差不多给了20k，其中17k基本工资，3k绩效，绩效正常的话2个月年终，社保公积金基数为基本工资，公积金12%比例。大概算下来就是30%左右的涨幅，算计的真好。每个月最后一个周六需要加班，工资翻倍，差不多那天能有一千来块的收入。

我纠结到底去不去，一旦去了外包我就没有回头路了。说是这么说，但我知道过去其实也是打杂，不知道能不能学习到什么，而且压力不知道咋样。朋友们也都在和我说，外包的地位那不是一般的低，也许华为里还好，因为od是当正式员工用的。但是技术提升我觉得不会特别高。

我一直认为工资可以稍微低一些，但是技术得提升。但是现在就挺矛盾，一是面不到好的公司，二是去中小型公司技术其实很难再提升了，三是工资也比原来低很多。

所以我现在纠结是不是应该先去od混着，然后顺便也继续面试，也是填补空窗期。虽然刚开始简历上不会写这段经历，但是可以继续尝试。但我也知道只要去了就会开始忙起来了，又开始无暇顾及面试，我是知道的。

其次我也担心一旦我去od超过一定时间，我简历上肯定会写上这份经历，外包经历肯定对简历有影响，一是面试机会少，二是影响面试官印象。但如果只是单纯赚钱的话，我觉得可以去，20k其实也不低了。一个月20不知道领先了多少人，真的我认为网络社区上高工资的人太多了，搞得人人都很焦虑，中国月入过万的人才多少？

有时候当你问出问题的那一刻，其实心里早就有了答案。你向其他人询问也只是为了坚定你的想法。

未来的路还很长，不必太过焦虑。这句话其实很多人都和我说过。我们对自己的未来感到迷茫恰恰是因为不甘平凡而已。我也经常这样安慰自己，但是说实话还是想多赚钱。人是矛盾的动物。

不知不觉胡言乱语一千多字，不知道写给谁看，只是想记录下此时的心情，想和自己和解，仅此而已。

今天zoom面试，亏我还那么期待，感觉好像面试官水平不咋样啊，面试完后一个小时直接发拒绝邮件了，我真是醉了，我感觉大部分回答的还可以吧，除了小部分不懂的问题，不会又是刷KPI的吧。艹！

全程基本都是八股文，有数据库相关，有java相关，我印象比较深的是一个explain的filesort没答上来，然后es的一个match和match_phrase好像答反了。不至于就挂掉啊，真奇怪。难道是我跟面试官说话的态度不好吗？好像有一两次我觉得他说的不对，反驳了一下。

算了，就不应该抱有期待的，就这样吧，复盘一下。

复盘

为什么用xxl-job？@scheduler和xxl-job

高可用部署+任务失败重试+多种调度方式+动态任务配置.

@Scheduled 注解是 Spring 的一部分，集成简单，适合在 Spring 环境中进行定时任务调度。适合单个应用程序内部的定时任务管理，不支持分布式任务调度。

XXL-JOB 是一个分布式任务调度平台，提供了更加全面和强大的任务调度功能，适用于大规模分布式系统的任务调度需求。支持分布式部署，可以在多个服务器或实例上运行调度任务，适用于分布式系统和大规模应用。支持多种调度方式，包括简单任务、分片任务、定时任务等。

xxl-job如何控制单一任务只有一次执行

在任务开始执行前，任务执行器会尝试获取任务的锁。通常使用数据库中的记录或分布式锁机制来确保任务只有一个实例在执行。

任务执行器会在任务执行前更新任务状态，例如在数据库中标记任务为“正在执行”。这有助于防止任务被重复下发或执行。

数据库的表锁和行锁

表锁是指对整个表施加锁定，确保在锁定期间，其他事务无法对该表进行修改或读取操作（具体行为取决于锁的类型）。表锁会锁定整个表，导致在锁定期间，其他事务无法访问该表。这可能会导致较大的并发访问瓶颈。

行锁是指对数据库表中的特定行施加锁定。行锁可以更细粒度地控制对表中数据的访问，通常在高并发环境中使用。行锁只锁定表中的特定行，允许其他事务访问表中的其他行。这可以提高并发性能和资源利用率。

行锁膨胀

当数据库中的锁定行数量非常多时，某些数据库系统可能会自动升级为表锁，以简化锁管理和避免过多的锁开销。这种情况被称为锁膨胀。

操作涉及整个表时，例如执行一个需要对整个表进行锁定的查询或更新，数据库系统可能会选择表锁以保证操作的完整性。例如在事务中执行了一条没有索引条件的查询，引发全表扫描，行锁 膨胀为表锁。

当行锁锁定的数据没有主键或唯一索引时，数据库系统可能会自动将行锁膨胀为表锁。

数据库的死锁？回滚事务如何处理？

看录像之后，发现答得不好。

表级锁死锁

假设有两个事务，分别在操作两个表：表A和表B。
事务1试图先锁定表A，然后锁定表B。
而事务2试图先锁定表B，然后锁定表A。
用户A和用户B加锁的顺序如下：

• 用户A–》表1（表锁）–》表2（表锁）
• 用户B–》表2（表锁）–》表1（表锁）

如果这两个事务同时执行，它们将会相互等待对方释放锁，从而导致死锁。

这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。

1. 仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，
2. 尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源。

行级锁死锁

原因1：

如果在事务中执行了一条没有索引条件的查询，引发全表扫描，行锁 膨胀 为表锁（ 或者等价于 表级锁）

多个这样的 锁表事务 执行后，就很容易产生死锁和阻塞，最终应用系统会越来越慢，发生阻塞或 死锁。

解决方案

1. SQL语句中不要使用太复杂的关联多表的查询；
2. 使用explain“执行计划”对SQL语句进行分析，对于有全表扫描和全表锁定的SQL语句，建立相应的索引进行优化。

原因2：

两个事务分别想拿到对方持有的锁，互相等待，于是产生死锁

1
2
3
4

Session_1执行：select * from account where id=1 for update;
Session_2执行：select * from account where id=2 for update;
Session_1执行：select * from account where id=2 for update;
Session_2执行：select * from account where id=1 for update;

这种情况下，mysql会自动检测死锁并回滚事务，按照AI的回答，mysql会自动分析回滚等待时间最长，回滚代价小，数据影响少的事务进行回滚。

xxl任务执行失败时的处理

• “故障转移”发生在调度阶段，在执行器集群部署时，如果某一台执行器发生故障，该策略支持自动进行Failover切换到一台正常的执行器机器并且完成调度请求流程。
• “失败重试”发生在”调度 + 执行”两个阶段，支持通过自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试；

mysql事务隔离级别？项目中使用的是什么？

• READ-UNCOMMITTED(读取未提交) ：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。
• READ-COMMITTED(读取已提交) ：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生。
• REPEATABLE-READ(可重复读) ：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。
• SERIALIZABLE(可串行化) ：最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。

mysql为什么使用RR级别？

Mysql在5.0这个版本以前，binlog只支持STATEMENT这种格式！

而这种格式在读已提交(Read Commited)这个隔离级别下主从复制是有bug的，因此Mysql将可重复读(Repeatable Read)作为默认的隔离级别

假设主节点两个事务A, B，并且隔离级别为RC，事务A先执行了删除操作，但是未提交事务；事务B执行了插入操作，先提交了事务。最后事务A提交事务。

此时主节点上查询应该是有数据的才对，因为delete早于insert。

但是由于提交时间不一样，所以bin log记录的顺序是先insert然后delete，导致从节点上无数据。

解决方案有两种！

1. 隔离级别设为可重复读(Repeatable Read),在该隔离级别下引入间隙锁。当Session 1执行delete语句时，会锁住间隙。那么，Ssession 2执行插入语句就会阻塞住！
2. 将binglog的格式修改为row格式，此时是基于行的复制，自然就不会出现sql执行顺序不一样的问题！奈何这个格式在mysql5.1版本开始才引入。因此由于历史原因，mysql将默认的隔离级别设为可重复读(Repeatable Read)，保证主从复制不出问题！

项目中选了哪个隔离级别？为什么？

项目中是不用读未提交(Read UnCommitted)和串行化(Serializable)两个隔离级别，原因有二

采用读未提交(Read UnCommitted),一个事务读到另一个事务未提交读数据，从逻辑上都说不过去！

采用串行化(Serializable)，每个次读操作都会加锁，快照读失效，一般是使用mysql自带分布式事务功能时才使用该隔离级别！

那为什么很多互联网大厂为选读已提交(Read Commited)作为事务隔离级别？

原因1：在RR隔离级别下，存在间隙锁，导致出现死锁的几率比RC大的多！

假设表数据如下，并执行sql

1
2
3
4
5
6
7
8
9
10

+----+-------+
| id | type  |
+----+-------+
|  1 |  red  |
|  2 | white |
|  5 |  red  |
|  7 | white |
+----+-------+

select * from test where id <3 for update;

在RR隔离级别下，存在间隙锁，可以锁住(2,5)这个间隙，防止其他事务插入数据！
而在RC隔离级别下，不存在间隙锁，其他事务是可以插入数据！

原因2：在RR隔离级别下，条件列未命中索引会锁表！而在RC隔离级别下，只锁行。

1

update test set type = 'blue' where type = 'white'; 

在RC隔离级别下，其先走聚簇索引，进行全部扫描

但在实际中，MySQL做了优化，发现不满足后，会调用unlock_row方法，把不满足条件的记录放锁。

然而，在RR隔离级别下，走聚簇索引，进行全部扫描，最后会将整个表锁上。

原因3：在RC隔离级别下，半一致性读(semi-consistent)特性增加了update操作的并发性

在5.1.15的时候，innodb引入了一个概念叫做“semi-consistent”，减少了更新同一行记录时的冲突，减少锁等待。
所谓半一致性读就是，一个update语句，如果读到一行已经加锁的记录，此时InnoDB返回记录最近提交的版本，由MySQL上层判断此版本是否满足update的where条件。若满足(需要更新)，则MySQL会重新发起一次读操作，此时会读取行的最新版本(并加锁)！

假设有两个事务，事务1和事务2！
事务1执行:

1

update test set type = 'blue' where type = 'red'; 

先不Commit事务！

与此同时事务2执行:

1

update test set type = 'blue' where type = 'white'; 

事务 2尝试加锁的时候，发现行上已经存在锁，InnoDB会开启semi-consistent read，返回最新的committed版本(1,red),(2，white),(5,red),(7,white)。MySQL会重新发起一次读操作，此时会读取行的最新版本(并加锁)!
而在RR隔离级别下，事务2只能等待！

在RC级别下，不可重复读问题需要解决么？

不用解决，这个问题是可以接受的！毕竟你数据都已经提交了，读出来本身就没有太大问题！Oracle的默认隔离级别就是RC。

可重复读实现原理

可重复读（Repeatable Read） 是 MySQL 的事务隔离级别之一，旨在保证在一个事务中多次读取相同数据时的结果一致性。为了实现这一点，MySQL 使用了 多版本并发控制（MVCC, Multi-Version Concurrency Control） 机制。

它是通过在每个数据行上维护多个版本的数据来实现的。当一个事务要对数据库中的数据进行修改时，MVCC 会为该事务创建一个数据快照，而不是直接修改实际的数据行。

MVCC 的实现依赖于：隐藏字段、Read View、undo log。在内部实现中，InnoDB 通过数据行的 DB_TRX_ID 和 Read View 来判断数据的可见性，如不可见，则通过数据行的 DB_ROLL_PTR 找到 undo log 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 Read View 之前已经提交的修改和该事务本身做的修改

隐藏字段

在内部，InnoDB 存储引擎为每行数据添加了三个 隐藏字段：

• DB_TRX_ID（6字节）：表示最后一次插入或更新该行的事务 id。此外，delete 操作在内部被视为更新，只不过会在记录头 Record header 中的 deleted_flag 字段将其标记为已删除
• DB_ROLL_PTR（7字节） 回滚指针，指向该行的 undo log 。如果该行未被更新，则为空
• DB_ROW_ID（6字节）：如果没有设置主键且该表没有唯一非空索引时，InnoDB 会使用该 id 来生成聚簇索引。

ReadView

Read View 主要是用来做可见性判断，里面保存了 “当前对本事务不可见的其他活跃事务”

主要有以下字段：

• m_low_limit_id：目前出现过的最大的事务 ID+1，即下一个将被分配的事务 ID。大于等于这个 ID 的数据版本均不可见
• m_up_limit_id：活跃事务列表 m_ids 中最小的事务 ID，如果 m_ids 为空，则 m_up_limit_id 为 m_low_limit_id。小于这个 ID 的数据版本均可见
• m_ids：Read View 创建时其他未提交的活跃事务 ID 列表。创建 Read View时，将当前未提交事务 ID 记录下来，后续即使它们修改了记录行的值，对于当前事务也是不可见的。m_ids 不包括当前事务自己和已提交的事务（正在内存中）
• m_creator_trx_id：创建该 Read View 的事务 ID

undo log

undo log 主要有两个作用：

• 当事务回滚时用于将数据恢复到修改前的样子
• 另一个作用是 MVCC ，当读取记录时，若该记录被其他事务占用或当前版本对该事务不可见，则可以通过 undo log 读取之前的版本数据，以此实现非锁定读

在 InnoDB 存储引擎中 undo log 分为两种：insert undo log 和 update undo log：

1. insert undo log：指在 insert 操作中产生的 undo log。因为 insert 操作的记录只对事务本身可见，对其他事务不可见，故该 undo log 可以在事务提交后直接删除。不需要进行 purge 操作
2. update undo log：update 或 delete 操作中产生的 undo log。该 undo log可能需要提供 MVCC 机制，因此不能在事务提交时就进行删除。提交时放入 undo log 链表，等待 purge线程 进行最后的删除.

数据可见性算法

在 InnoDB 存储引擎中，创建一个新事务后，执行每个 select 语句前，都会创建一个快照（Read View），快照中保存了当前数据库系统中正处于活跃（没有 commit）的事务的 ID 号。其实简单的说保存的是系统中当前不应该被本事务看到的其他事务 ID 列表（即 m_ids）。当用户在这个事务中要读取某个记录行的时候，InnoDB 会将该记录行的 DB_TRX_ID 与 Read View 中的一些变量及当前事务 ID 进行比较，判断是否满足可见性条件。

RC 和 RR 隔离级别下 MVCC 的差异

在事务隔离级别 RC 和 RR （InnoDB 存储引擎的默认事务隔离级别）下，InnoDB 存储引擎使用 MVCC（非锁定一致性读），但它们生成 Read View 的时机却不同

• 在 RC 隔离级别下的 每次select 查询前都生成一个Read View (m_ids 列表)
• 在 RR 隔离级别下只在事务开始后 第一次select 数据前生成一个Read View（m_ids 列表）

声明式事务标记在private方法上

无法生效，因为声明式事务是基于AOP实现的。Spring 生成的代理对象仅能拦截 public 方法，因为代理对象是 public 方法的拦截器，而无法直接拦截 private 方法。因此，private 方法上的 @Transactional 注解不会被 Spring 事务管理器识别和应用。

explain分析有哪些指标

id

• 描述：查询的唯一标识符，通常用于标识查询中的不同 SELECT 或 UNION 子句的执行顺序。
• 意义：在复杂查询中，id 指标帮助你理解查询的执行顺序和逻辑结构。

select_type

• SIMPLE：简单的查询，不包括子查询或 UNION。
• PRIMARY：最外层的 SELECT 查询。
• UNION：UNION 中的 SELECT 查询。
• SUBQUERY：子查询中的 SELECT 查询。
• DERIVED：派生表（子查询中的 SELECT）中的查询。

table

显示查询涉及的表。

type

• system：表只有一行，最优。
• const：用于匹配常量，效率很高。
• eq_ref：通过唯一索引进行匹配，效率高。
• ref：非唯一索引匹配，效率较高。
• range：范围查询（使用索引进行范围查找）。
• index：全索引扫描，效率低于使用索引的其他方式。
• ALL：全表扫描，最差，性能较低。

possible_keys

列出查询中可能用到的索引。

key

实际使用的索引。了解查询中实际使用了哪个索引。与 possible_keys 对比，确定是否选择了最优的索引。

key_len

表示实际使用的索引的长度（字节数）。通过分析 key_len，可以了解使用的索引的有效性。较长的 key_len 可能意味着索引覆盖了更多的列。

ref

显示哪些列或常量用于索引查找。

rows

表示 MySQL 估算需要读取的行数。估算的行数可以帮助你了解查询的复杂性。较高的行数可能意味着查询会扫描大量数据，从而影响性能。

filtered

表示在读取的行中，多少百分比的行被过滤掉（即匹配条件的行）。

extra

• Using index：查询只使用了索引，没有访问表数据，通常意味着索引覆盖了查询。
• Using where：查询使用了 WHERE 子句来过滤结果。
• Using temporary：查询使用了临时表，通常意味着查询需要复杂的处理，可能会影响性能。
• Using filesort：查询需要额外的排序操作，通常意味着性能较差。

extra的file sort是什么情况？如何优化

当 Using filesort 出现时，意味着 MySQL 必须对结果集进行排序，但不能使用索引中的数据直接进行排序。因此，MySQL 使用临时文件来完成排序过程。

Using filesort 发生在以下情况：

1. 无法使用索引排序：如果查询中需要对结果集进行排序，但所用的索引不能满足排序需求，MySQL 会使用额外的排序步骤。即使使用了索引，排序顺序可能与查询中的排序要求不匹配。
2. 多个排序条件：当查询中有多个排序条件时，索引可能无法完全满足所有排序要求，从而需要额外的排序操作。
3. ORDER BY 不匹配索引顺序：即使有索引，如果 ORDER BY 子句中的排序顺序与索引的顺序不匹配，也会触发文件排序。

如何优化?

使用合适的索引：确保你的 ORDER BY 子句中的字段有适当的索引。如果排序字段与 WHERE 子句中的字段有共同的索引，那么 MySQL 可能会使用这个索引进行排序。

优化查询: 如果排序不是必需的，可以考虑删除 ORDER BY 子句或优化排序条件，以减少对排序操作的需求。尽量简化排序字段。例如，如果只需对一个字段进行排序，确保只在该字段上创建索引，而不是包括多个字段。

使用索引覆盖查询: 如果查询只涉及到索引中的字段，MySQL 可以使用覆盖索引来避免回表操作。在这种情况下，排序可以直接通过索引完成，无需额外的文件排序。

1
2
3

SELECT column1, column2 FROM table
WHERE column1 = 'value'
ORDER BY column2;

这里的 column1 和 column2 都应该在索引中，以便可以使用索引直接排序。

调整配置参数: **调整 sort_buffer_size**：增加 sort_buffer_size 配置参数的值可以提高排序操作的效率，减少文件排序的频率。这是 MySQL 在排序操作中使用的内存缓冲区的大小。

事务提交后，如何执行一些后置处理？如何知道事务已经提交？

不查不知道，一查吓一跳，原来有这么多方法。

使用 TransactionSynchronizationManager 和 TransactionSynchronization

Spring 提供了 TransactionSynchronizationManager 和 TransactionSynchronization 机制，可以在事务提交后执行自定义逻辑。这是一种非常灵活的方法，可以在事务提交后注册回调方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

import org.springframework.transaction.support.TransactionSynchronization;
import org.springframework.transaction.support.TransactionSynchronizationManager;

public class MyTransactionSynchronization implements TransactionSynchronization {
    @Override
    public void beforeCommit(boolean readOnly) {
        // Do nothing
    }

    @Override
    public void afterCommit() {
        // 执行事务提交后的处理逻辑
        System.out.println("事务已经提交");
    }

    @Override
    public void afterCompletion(int status) {
        // 事务完成后的处理
        if (status == STATUS_COMMITTED) {
            System.out.println("事务提交完成");
        } else if (status == STATUS_ROLLED_BACK) {
            System.out.println("事务回滚");
        }
    }

    @Override
    public void beforeCompletion() {
        // Do nothing
    }

    @Override
    public void suspend() {
        // Do nothing
    }

    @Override
    public void resume() {
        // Do nothing
    }
}

在需要执行后置处理的地方注册 TransactionSynchronization：

1
2
3
4
5
6
7
8
9
10

import org.springframework.transaction.support.TransactionSynchronizationManager;

public class MyService {
    public void myTransactionalMethod() {
        // 业务逻辑
        
        // 注册 TransactionSynchronization
        TransactionSynchronizationManager.registerSynchronization(new MyTransactionSynchronization());
    }
}

使用 @Transactional 注解的 afterCommit 和 afterRollback 属性

还真没用过。。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

import org.springframework.transaction.annotation.Transactional;

public class MyTransactionalService {
    
    @Transactional
    public void myTransactionalMethod() {
        // 业务逻辑
    }

    @Transactional(afterCommit = "postCommit")
    public void myTransactionalMethodWithCallback() {
        // 业务逻辑
    }

    public void postCommit() {
        // 事务提交后的处理逻辑
        System.out.println("事务提交后处理");
    }
}

使用 ApplicationListener 监听事务事件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import org.springframework.context.ApplicationListener;
import org.springframework.transaction.event.TransactionPhase;
import org.springframework.transaction.event.TransactionalEventListener;
import org.springframework.transaction.event.TransactionPhase;
import org.springframework.transaction.support.TransactionSynchronizationManager;

public class MyTransactionEventListener {

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handleAfterCommit() {
        // 事务提交后的处理逻辑
        System.out.println("事务已经提交，执行后置处理");
    }

    @TransactionalEventListener(phase = TransactionPhase.AFTER_ROLLBACK)
    public void handleAfterRollback() {
        // 事务回滚后的处理逻辑
        System.out.println("事务回滚");
    }
}

注册监听器

1
2
3
4

@Bean
public MyTransactionEventListener myTransactionEventListener() {
    return new MyTransactionEventListener();
}

使用 TransactionCallback

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.TransactionCallback;
import org.springframework.transaction.support.TransactionCallbackWithoutResult;
import org.springframework.transaction.support.TransactionTemplate;

public class MyService {
    
    private final TransactionTemplate transactionTemplate;

    public MyService(PlatformTransactionManager transactionManager) {
        this.transactionTemplate = new TransactionTemplate(transactionManager);
    }

    public void myTransactionalMethod() {
        transactionTemplate.execute(new TransactionCallbackWithoutResult() {
            @Override
            protected void doInTransactionWithoutResult(TransactionStatus status) {
                // 业务逻辑
                
                // 事务提交后的处理
                System.out.println("事务已经提交，执行后置处理");
            }
        });
    }
}

深度分页查询优化

1
2

# MySQL 在无法利用索引的情况下跳过1000000条记录后，再获取10条记录
SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10

基于游标的分页

1

SELECT * FROM table WHERE id > ? ORDER BY id LIMIT 10;

在第一次查询中，? 是初始的游标值（例如，0），在后续查询中，它是上一次查询的最后一条记录的 id。

这种优化方式限制比较大，且一般项目的 ID 也没办法保证完全连续。

子查询

阿里巴巴《Java 开发手册》中也有对应的描述：

利用延迟关联或者子查询优化超多分页场景。

1
2

# 通过子查询来获取 id 的起始值，把 limit 1000000 的条件转移到子查询
SELECT * FROM t_order WHERE id >= (SELECT id FROM t_order limit 1000000, 1) LIMIT 10;

不过，子查询的结果会产生一张新表，会影响性能，应该尽量避免大量使用子查询。并且，这种方法只适用于 ID 是正序的。在复杂分页场景，往往需要通过过滤条件，筛选到符合条件的 ID，此时的 ID 是离散且不连续的。

延迟关联

延迟关联的优化思路，跟子查询的优化思路其实是一样的：都是把条件转移到主键索引树，减少回表的次数。不同点是，延迟关联使用了 INNER JOIN（内连接） 包含子查询。

1
2
3

SELECT t1.* FROM t_order t1
INNER JOIN (SELECT id FROM t_order limit 1000000, 10) t2
ON t1.id = t2.id;

除了使用 INNER JOIN 之外，还可以使用逗号连接子查询

1
2
3

SELECT t1.* FROM t_order t1,
(SELECT id FROM t_order limit 1000000, 10) t2
WHERE t1.id = t2.id;

覆盖索引

索引中已经包含了所有需要获取的字段的查询方式称为覆盖索引。

避免 InnoDB 表进行索引的二次查询，也就是回表操作: InnoDB 是以聚集索引的顺序来存储的，对于 InnoDB 来说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二级索引的键值中可以获取所有的数据，避免了对主键的二次查询（回表），减少了 IO 操作，提升了查询效率。

可以把随机 IO 变成顺序 IO 加快查询效率: 由于覆盖索引是按键值的顺序存储的，对于 IO 密集型的范围查找来说，对比随机从磁盘读取每一行的数据 IO 要少的多，因此利用覆盖索引在访问时也可以把磁盘的随机读取的 IO 转变成索引查找的顺序 IO。

1
2
3
4

# 如果只需要查询 id, code, type 这三列，可建立 code 和 type 的覆盖索引
SELECT id, code, type FROM t_order
ORDER BY code
LIMIT 1000000, 10;

不过，当查询的结果集占表的总行数的很大一部分时，可能就不会走索引了，自动转换为全表扫描。当然了，也可以通过 FORCE INDEX 来强制查询优化器走索引，但这种提升效果一般不明显。

什么是倒排索引

倒排索引 也被称作反向索引（inverted index），是用于提高数据检索速度的一种数据结构，空间消耗比较大。倒排索引首先将检索文档进行分词得到多个词语/词条，然后将词语和文档 ID 建立关联，从而提高检索效率。

倒排索引使用 词语/词条（Term） 来作为索引关键字，并同时记录了哪些 文档（Document） 中有这个词语。

match query和term query

说实话没用过。。。

match 查询用于全文搜索，通常用于检索文档中包含某个单词或短语的文档。match 查询会经过分词（Tokenization）过程，将查询词分解成多个词项，然后进行搜索。这意味着 match 查询适合处理用户输入的自然语言文本。

term 查询用于精确匹配，通常用于检索字段中确切匹配的值。这意味着 term 查询不会经过分析或分词过程，适合用于关键词、标识符或固定的值。

使用redis分布式锁如何解决主从同步问题

确保写操作在主节点：所有的分布式锁操作（包括获取和释放锁）都应该在主节点上执行。这样可以保证在任何时候，锁的状态都是最新的。

避免在从节点上执行锁操作：在设计系统时，确保所有的锁操作请求都不会被重定向到从节点。这可以通过客户端库来实现，或者在应用层面进行控制。

使用 RedLock 算法：RedLock 是一种设计用于 Redis 的分布式锁获取算法，它通过在多个 Redis 节点上尝试获取锁来提高锁的安全性。如果 Redis 集群使用了主从复制，RedLock 算法可以确保锁的安全性。

监控主从复制延迟：监控主从复制的延迟情况，如果延迟过高，可能需要考虑优化复制性能或重新评估锁的超时时间。

redission中也进行了一些处理

1. 多节点锁获取：Redisson 通过在所有的 Redis 服务器上尝试获取锁来实现这一点。即使在主从复制的环境中，这样也能确保锁的安全性
2. 自动检测和配置主从节点：Redisson 提供了自动检测和配置主从节点的功能，这有助于设置主从复制并保持数据一致性

redis分布式锁保证安全性？不会被其他线程操作？

• 使用 SET 命令的 NX 选项：这确保了只有当 key 不存在时，才能设置成功，从而避免了多个客户端同时获取锁。
• 设置合理的超时时间：使用 EX 或 PX 选项设置超时时间，确保即使客户端出现问题，锁也能在一定时间后自动释放。

分布式锁的值可以设置成UUID或者服务标识+线程标识，只要确保唯一。释放锁时，需要先判断现值与获取锁时的标识是否一致。

1

if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end

mybatis缓存机制

MyBatis 提供了两种缓存机制：一级缓存（本地缓存）和 二级缓存（全局缓存）。

一级缓存是 MyBatis 的本地缓存，每次 SQL 查询会在当前 SqlSession 中缓存查询结果。一级缓存的生命周期与 SqlSession 绑定，即 SqlSession 在关闭时缓存会被清空。

作用范围：每个 SqlSession 具有自己的一级缓存，缓存的数据只能在当前 SqlSession 内部访问。

自动生效：MyBatis 默认启用一级缓存，不需要额外配置。

缓存清空：在以下情况下一级缓存会被清空：

• SqlSession 的 commit() 或 rollback() 操作。
• 执行了 clearCache() 方法。
• 执行了增、删、改操作（因为这些操作可能影响到缓存的有效性）。

二级缓存是 MyBatis 的全局缓存，缓存的生命周期与 SqlSessionFactory 绑定，跨多个 SqlSession 实例共享。适用于多个 SqlSession 使用相同的数据源的情况。

作用范围：多个 SqlSession 可以共享二级缓存，缓存的数据可以被不同的 SqlSession 访问。

需要配置：二级缓存需要在 MyBatis 配置文件中启用，并为每个 Mapper 映射器配置缓存。

缓存清空：当执行增、删、改操作时，相关的缓存会被清空。

脏数据问题：二级缓存可能导致脏数据问题，因为多个 SqlSession 可能共享相同的缓存数据。如果一个 SqlSession 更新了数据但没有及时清空或更新缓存，其他 SqlSession 可能会读取到旧的数据。

缓存失效条件

• 一级缓存：在 SqlSession 执行插入、更新或删除操作后，默认会清空一级缓存。
• 二级缓存：在执行插入、更新或删除操作后，如果配置了相应的映射语句的 flushCache 属性为 true，则会清空涉及的命名空间的二级缓存。

mybatis什么时候读取会产生脏数据

多会话并发操作：在多线程或多会话环境中，如果一个会话（SqlSession）读取了数据并将其缓存，而另一个会话对相同的数据进行了修改并提交了事务，那么第一个会话的缓存就会变成脏数据。

缓存未设置为只读：MyBatis的二级缓存默认是只读的（readOnly属性为true），这意味着缓存的数据不会被修改。如果错误地将缓存设置为可写（readOnly属性为false），那么缓存的数据可能会被修改，导致脏数据。

事务管理不当: 事务的隔离级别可能不够高，导致其他事务能看到未提交的数据。MyBatis 的一级缓存和二级缓存都受事务管理的影响，事务的隔离级别可能导致缓存中的数据与数据库中的实际数据不一致。

缓存键不准确：如果缓存键的生成逻辑不正确，可能会导致不同的数据请求被错误地映射到同一个缓存键，从而覆盖彼此的数据，产生脏数据。

从AI回答中挑了几个可能原因。

sql监控插件如何实现

使用 MyBatis 自定义拦截器

MyBatis 提供了拦截器机制，可以拦截执行 SQL 的关键点，例如 Executor、StatementHandler、ResultSetHandler 等。通过自定义拦截器，可以在 SQL 执行前后记录时间，并计算执行耗时。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

import org.apache.ibatis.executor.Executor;
import org.apache.ibatis.mapping.MappedStatement;
import org.apache.ibatis.plugin.*;

import java.util.Properties;

@Intercepts({
        @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class}),
        @Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class})
})
public class SqlTimeInterceptor implements Interceptor {

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        long startTime = System.currentTimeMillis();
        try {
            return invocation.proceed();  // 执行SQL
        } finally {
            long endTime = System.currentTimeMillis();
            long executionTime = endTime - startTime;

            MappedStatement mappedStatement = (MappedStatement) invocation.getArgs()[0];
            String sqlId = mappedStatement.getId();

            System.out.println("SQL [" + sqlId + "] 执行耗时: " + executionTime + " ms");
        }
    }

    @Override
    public Object plugin(Object target) {
        return Plugin.wrap(target, this);
    }

    @Override
    public void setProperties(Properties properties) {
        // 可配置属性
    }
}

然后注册这个拦截器

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

import org.apache.ibatis.session.SqlSessionFactory;
import org.mybatis.spring.boot.autoconfigure.MybatisProperties;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class MybatisConfig {

    @Autowired
    private MybatisProperties mybatisProperties;

    @Bean
    public SqlSessionFactory sqlSessionFactory(javax.sql.DataSource dataSource) throws Exception {
        org.apache.ibatis.session.Configuration configuration = new org.apache.ibatis.session.Configuration();
        configuration.setDataSource(dataSource);

        // 注册自定义拦截器
        SqlTimeInterceptor sqlTimeInterceptor = new SqlTimeInterceptor();
        configuration.addInterceptor(sqlTimeInterceptor);

        org.mybatis.spring.SqlSessionFactoryBean sessionFactoryBean = new org.mybatis.spring.SqlSessionFactoryBean();
        sessionFactoryBean.setDataSource(dataSource);
        sessionFactoryBean.setConfiguration(configuration);

        return sessionFactoryBean.getObject();
    }
}

使用 MyBatis-Plus 内置功能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import com.baomidou.mybatisplus.extension.plugins.PerformanceInterceptor;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class MybatisPlusConfig {

    @Bean
    public PerformanceInterceptor performanceInterceptor() {
        PerformanceInterceptor performanceInterceptor = new PerformanceInterceptor();
        performanceInterceptor.setMaxTime(1000); // 设置SQL最大执行时间，超过将抛出异常
        performanceInterceptor.setFormat(true);  // 格式化SQL输出
        return performanceInterceptor;
    }
}

mq如何保证顺序性

Kafka通过分区（partition）来保证消息的顺序性。在Kafka中，消息在每个分区内是按顺序存储的，消费者在读取消息时也是按照这个顺序读取的。只要消息被写入同一个分区，Kafka就能保证这些消息在消费时是按照生产的顺序被处理的。

如果希望保证某些消息的顺序性（例如，某个用户的所有操作日志必须按顺序处理），可以使用消息键（key）来控制消息的分区选择。Kafka根据消息键对分区数取模（hashing），将具有相同键的消息放入同一个分区，从而保证了这些消息在分区内的顺序。

消费者组中的每个消费者消费一个或多个分区，从而保证了这些消息在单个消费者内的顺序。

在RabbitMQ中，消息在队列中是按顺序存储的，消费者从队列中消费消息时，消息的消费顺序与生产顺序一致。因此，使用一个队列并确保一个消费者处理队列中的消息时，可以保证消息的顺序性。

如果多个消费者同时从同一个队列中消费，RabbitMQ会以轮询方式分配消息，这可能导致顺序被打乱。因此，如果需要严格的顺序，应该使用单个消费者。

通过设计不同的队列来处理顺序性。例如，如果有多种类型的消息需要保持顺序，可以为每种类型创建单独的队列，并保证每个队列由一个消费者处理。

队列能有多少消费者

这个问题我面试之后挺气的。面试官说我topic和队列搞混了，他应该认为分区是队列的概念。查了一下，其实当成队列也没毛病，是我孤陋寡闻了。

可以简单理解成kafka分区就是队列。

kafka

单个消费者组内的消费者数量：受限于topic的分区数量，最多可以有与分区数相同的消费者并行消费。如果消费者数量超过分区数，多余的消费者将处于空闲状态。

多个消费者组：Kafka允许同一个topic有多个消费者组，每个消费者组的消费者数与分区数的关系相同。多个消费者组可以独立并行消费同一个topic，从而允许无限制数量的消费者整体上并行消费。

rabbitmq

理论上，RabbitMQ能支持的消费者数量没有固定的上限。但实际可支持的消费者数量取决于服务器的资源（CPU、内存、网络带宽）、RabbitMQ的配置以及消息处理的速度。

线程池如何设置核心线程数和最大线程数

核心线程数：

1. CPU密集型任务：核心线程数 = CPU核心数 + 1
2. I/O密集型任务：核心线程数 = CPU核心数 * 2 或 核心线程数 = CPU核心数 * (1 + 任务等待时间/任务执行时间)。

最大线程数：

最大线程数是线程池中允许存在的最大线程数。当任务数超过核心线程数并且队列已满时，线程池会创建新线程，直到达到最大线程数。如果线程数达到了最大值，新的任务将被拒绝。最大线程数应该足够大，以应对高峰负载时的需求，但也不宜过大，以免系统资源耗尽导致性能下降。

对于大多数I/O密集型应用，最大线程数通常设置为核心线程数的2倍或3倍。

对于CPU密集型应用，最大线程数可以设置为核心线程数或略大一些。

在一个线程池中，核心线程数为3，最大线程数为10，此时有五个任务提交，会有多少个线程产生

这题原来我答错了。要复习一下线程池的处理逻辑。

1. 如果当前运行的线程数小于核心线程数，那么就会新建一个线程来执行任务。
2. 如果当前运行的线程数等于或大于核心线程数，但是小于最大线程数，那么就把该任务放入到任务队列里等待执行。
3. 如果向任务队列投放任务失败（任务队列已经满了），但是当前运行的线程数是小于最大线程数的，就新建一个线程来执行任务。
4. 如果当前运行的线程数已经等同于最大线程数了，新建线程将会使当前运行的线程超出最大线程数，那么当前任务会被拒绝，拒绝策略会调用RejectedExecutionHandler.rejectedExecution()方法。

gpt给我的解答是：

情景1：使用无界队列（如LinkedBlockingQueue）

• 核心线程数（3）：首先，线程池会尝试使用核心线程来处理任务。如果核心线程数未达到上限，那么新任务会直接创建新线程来执行，直到核心线程数达到3。
• 最大线程数（10）：如果所有核心线程都在工作，而队列没有容量限制，那么新任务会被放入队列中，而不会创建新的线程。
• 五个任务提交的处理方式：
  1. 线程池会创建3个核心线程来处理前3个任务。
  2. 剩余的两个任务会被放入队列，等待空闲线程来处理。
• 最终结果：线程池将会有3个活跃线程在处理任务。

情景2：使用直接提交策略（如SynchronousQueue）

• 直接提交策略：使用SynchronousQueue时，每个任务必须被立即处理或执行，如果没有空闲线程来处理新任务，则会创建新的线程，直到达到最大线程数。
• 五个任务提交的处理方式：
  1. 线程池会创建3个核心线程来处理前3个任务。
  2. 剩余的两个任务由于没有空闲线程可用，线程池会创建2个非核心线程（达到最大线程数5）来处理这两个任务。
• 最终结果：线程池将会有5个活跃线程在处理任务。

我对比了一下，gpt说的没有错。SynchronousQueue是没有容量的。所以会直接创建线程去处理。

后话

复盘下来，好像确实有比较多的问题答得不好，比如mybatis相关，还有最后一个线程池相关我也记错了。

在此向两位面试官道歉，虽然面试过程中并没有特别不愉快，但是一个小时后就发拒绝邮件使我变得暴躁，把原因都归结于你们的不专业上，但是复盘之后发现是自己水平不够，很多问题即使有文档帮助依旧回答的不够好。在此郑重道歉。

MySQL 日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 binlog（归档日志）和事务日志 redo log（重做日志）和 undo log（回滚日志）。

redo log

redo log（重做日志）是 InnoDB 存储引擎独有的，它让 MySQL 拥有了崩溃恢复能力。

比如 MySQL 实例挂了或宕机了，重启时，InnoDB 存储引擎会使用 redo log 恢复数据，保证数据的持久性与完整性。

MySQL 中数据是以页为单位，你查询一条记录，会从硬盘把一页的数据加载出来，加载出来的数据叫数据页，会放入到 Buffer Pool 中。

后续的查询都是先从 Buffer Pool 中找，没有命中再去硬盘加载，减少硬盘 IO 开销，提升性能。

更新表数据的时候，也是如此，发现 Buffer Pool 里存在要更新的数据，就直接在 Buffer Pool 里更新。

然后会把“在某个数据页上做了什么修改”记录到重做日志缓存（redo log buffer）里，接着刷盘到 redo log 文件里。

理想情况，事务一提交就会进行刷盘操作，但实际上，刷盘的时机是根据策略来进行的。

InnoDB 将 redo log 刷到磁盘上有几种情况：

1. 事务提交：当事务提交时，log buffer 里的 redo log 会被刷新到磁盘（可以通过innodb_flush_log_at_trx_commit参数控制，后文会提到）。
2. log buffer 空间不足时：log buffer 中缓存的 redo log 已经占满了 log buffer 总容量的大约一半左右，就需要把这些日志刷新到磁盘上。
3. 事务日志缓冲区满：InnoDB 使用一个事务日志缓冲区（transaction log buffer）来暂时存储事务的重做日志条目。当缓冲区满时，会触发日志的刷新，将日志写入磁盘。
4. Checkpoint（检查点）：InnoDB 定期会执行检查点操作，将内存中的脏数据（已修改但尚未写入磁盘的数据）刷新到磁盘，并且会将相应的重做日志一同刷新，以确保数据的一致性。
5. 后台刷新线程：InnoDB 启动了一个后台线程，负责周期性（每隔 1 秒）地将脏页（已修改但尚未写入磁盘的数据页）刷新到磁盘，并将相关的重做日志一同刷新。
6. 正常关闭服务器：MySQL 关闭的时候，redo log 都会刷入到磁盘里去。

总之，InnoDB 在多种情况下会刷新重做日志，以保证数据的持久性和一致性。

我们要注意设置正确的刷盘策略innodb_flush_log_at_trx_commit 。根据 MySQL 配置的刷盘策略的不同，MySQL 宕机之后可能会存在轻微的数据丢失问题。

innodb_flush_log_at_trx_commit 的值有 3 种，也就是共有 3 种刷盘策略：

• 0：设置为 0 的时候，表示每次事务提交时不进行刷盘操作。这种方式性能最高，但是也最不安全，因为如果 MySQL 挂了或宕机了，可能会丢失最近 1 秒内的事务。
• 1：设置为 1 的时候，表示每次事务提交时都将进行刷盘操作。这种方式性能最低，但是也最安全，因为只要事务提交成功，redo log 记录就一定在磁盘里，不会有任何数据丢失。
• 2：设置为 2 的时候，表示每次事务提交时都只把 log buffer 里的 redo log 内容写入 page cache（文件系统缓存）。page cache 是专门用来缓存文件的，这里被缓存的文件就是 redo log 文件。这种方式的性能和安全性都介于前两者中间。

刷盘策略innodb_flush_log_at_trx_commit 的默认值为 1，设置为 1 的时候才不会丢失任何数据。为了保证事务的持久性，我们必须将其设置为 1。

另外，InnoDB 存储引擎有一个后台线程，每隔1 秒，就会把 redo log buffer 中的内容写到文件系统缓存（page cache），然后调用 fsync 刷盘。

一个没有提交事务的 redo log 记录，也可能会刷盘。

因为在事务执行过程 redo log 记录是会写入redo log buffer 中，这些 redo log 记录会被后台线程刷盘。

日志文件组

硬盘上存储的 redo log 日志文件不只一个，而是以一个日志文件组的形式出现的，每个的redo日志文件大小都是一样的。

比如可以配置为一组4个文件，每个文件的大小是 1GB，整个 redo log 日志文件组可以记录4G的内容。

在这个日志文件组中还有两个重要的属性，分别是 write pos、checkpoint

• write pos 是当前记录的位置，一边写一边后移
• checkpoint 是当前要擦除的位置，也是往后推移

每次刷盘 redo log 记录到日志文件组中，write pos 位置就会后移更新。

每次 MySQL 加载日志文件组恢复数据时，会清空加载过的 redo log 记录，并把 checkpoint 后移更新。

write pos 和 checkpoint 之间的还空着的部分可以用来写入新的 redo log 记录。

如果 write pos 追上 checkpoint ，表示日志文件组满了，这时候不能再写入新的 redo log 记录，MySQL 得停下来，清空一些记录，把 checkpoint 推进一下。

在 MySQL 8.0.30 之前可以通过 innodb_log_files_in_group 和 innodb_log_file_size 配置日志文件组的文件数和文件大小，但在 MySQL 8.0.30 及之后的版本中，这两个变量已被废弃，即使被指定也是用来计算 innodb_redo_log_capacity 的值。而日志文件组的文件数则固定为 32，文件大小则为 innodb_redo_log_capacity / 32 。

bin log

redo log 它是物理日志，记录内容是“在某个数据页上做了什么修改”，属于 InnoDB 存储引擎。

而 binlog 是逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于MySQL Server 层。

不管用什么存储引擎，只要发生了表数据更新，都会产生 binlog 日志。

可以说 MySQL 数据库的数据备份、主备、主主、主从都离不开 binlog，需要依靠 binlog 来同步数据，保证数据一致性。

binlog 会记录所有涉及更新数据的逻辑操作，并且是顺序写。

binlog 日志有三种格式，可以通过binlog_format参数指定。

• statement
• row
• mixed

指定statement，记录的内容是SQL语句原文，比如执行一条update T set update_time=now() where id=1，记录的内容如下。

同步数据时，会执行记录的SQL语句，但是有个问题，update_time=now()这里会获取当前系统时间，直接执行会导致与原库的数据不一致。

为了解决这种问题，我们需要指定为row，记录的内容不再是简单的SQL语句了，还包含操作的具体数据。

row格式记录的内容看不到详细信息，要通过mysqlbinlog工具解析出来。

update_time=now()变成了具体的时间update_time=1627112756247，条件后面的@1、@2、@3 都是该行数据第 1 个~3 个字段的原始值（假设这张表只有 3 个字段）。

这样就能保证同步数据的一致性，通常情况下都是指定为row，这样可以为数据库的恢复与同步带来更好的可靠性。

但是这种格式，需要更大的容量来记录，比较占用空间，恢复与同步时会更消耗 IO 资源，影响执行速度。

所以就有了一种折中的方案，指定为mixed，记录的内容是前两者的混合。

MySQL 会判断这条SQL语句是否可能引起数据不一致，如果是，就用row格式，否则就用statement格式。

写入机制

binlog 的写入时机也非常简单，事务执行过程中，先把日志写到binlog cache，事务提交的时候，再把binlog cache写到 binlog 文件中。

因为一个事务的 binlog 不能被拆开，无论这个事务多大，也要确保一次性写入，所以系统会给每个线程分配一个块内存作为binlog cache。

我们可以通过binlog_cache_size参数控制单个线程 binlog cache 大小，如果存储内容超过了这个参数，就要暂存到磁盘（Swap）。

write和fsync的时机，可以由参数sync_binlog控制，默认是1。

为0的时候，表示每次提交事务都只write，由系统自行判断什么时候执行fsync。

虽然性能得到提升，但是机器宕机，page cache里面的 binlog 会丢失。

为了安全起见，可以设置为1，表示每次提交事务都会执行fsync，就如同 redo log 日志刷盘流程 一样。

最后还有一种折中方式，可以设置为N(N>1)，表示每次提交事务都write，但累积N个事务后才fsync。

在出现 IO 瓶颈的场景里，将sync_binlog设置成一个比较大的值，可以提升性能。

同样的，如果机器宕机，会丢失最近N个事务的 binlog 日志。

两阶段提交

redo log（重做日志）让 InnoDB 存储引擎拥有了崩溃恢复能力。

binlog（归档日志）保证了 MySQL 集群架构的数据一致性。

虽然它们都属于持久化的保证，但是侧重点不同。

在执行更新语句过程，会记录 redo log 与 binlog 两块日志，以基本的事务为单位，redo log 在事务执行过程中可以不断写入，而 binlog 只有在提交事务时才写入，所以 redo log 与 binlog 的写入时机不一样。

回到正题，redo log 与 binlog 两份日志之间的逻辑不一致，会出现什么问题？

我们以update语句为例，假设id=2的记录，字段c值是0，把字段c值更新成1，SQL语句为update T set c=1 where id=2。

假设执行过程中写完 redo log 日志后，binlog 日志写期间发生了异常，会出现什么情况呢？

由于 binlog 没写完就异常，这时候 binlog 里面没有对应的修改记录。因此，之后用 binlog 日志恢复数据时，就会少这一次更新，恢复出来的这一行c值是0，而原库因为 redo log 日志恢复，这一行c值是1，最终数据不一致。

为了解决两份日志之间的逻辑一致问题，InnoDB 存储引擎使用两阶段提交方案。

原理很简单，将 redo log 的写入拆成了两个步骤prepare和commit，这就是两阶段提交。

使用两阶段提交后，写入 binlog 时发生异常也不会有影响，因为 MySQL 根据 redo log 日志恢复数据时，发现 redo log 还处于prepare阶段，并且没有对应 binlog 日志，就会回滚该事务。

undo log

每一个事务对数据的修改都会被记录到 undo log ，当执行事务过程中出现错误或者需要执行回滚操作的话，MySQL 可以利用 undo log 将数据恢复到事务开始之前的状态。

undo log 属于逻辑日志，记录的是 SQL 语句，比如说事务执行一条 DELETE 语句，那 undo log 就会记录一条相对应的 INSERT 语句。同时，undo log 的信息也会被记录到 redo log 中，因为 undo log 也要实现持久性保护。并且，undo-log 本身是会被删除清理的，例如 INSERT 操作，在事务提交之后就可以清除掉了；UPDATE/DELETE 操作在事务提交不会立即删除，会加入 history list，由后台线程 purge 进行清理。

undo log 是采用 segment（段）的方式来记录的，每个 undo 操作在记录的时候占用一个 undo log segment（undo 日志段），undo log segment 包含在 rollback segment（回滚段）中。事务开始时，需要为其分配一个 rollback segment。每个 rollback segment 有 1024 个 undo log segment，这有助于管理多个并发事务的回滚需求。

通常情况下， rollback segment header（通常在回滚段的第一个页）负责管理 rollback segment。rollback segment header 是 rollback segment 的一部分，通常在回滚段的第一个页。history list 是 rollback segment header 的一部分，它的主要作用是记录所有已经提交但还没有被清理（purge）的事务的 undo log。这个列表使得 purge 线程能够找到并清理那些不再需要的 undo log 记录。

另外，MVCC 的实现依赖于：隐藏字段、Read View、undo log。在内部实现中，InnoDB 通过数据行的 DB_TRX_ID 和 Read View 来判断数据的可见性，如不可见，则通过数据行的 DB_ROLL_PTR 找到 undo log 中的历史版本。每个事务读到的数据版本可能是不一样的，在同一个事务中，用户只能看到该事务创建 Read View 之前已经提交的修改和该事务本身做的修改。

总结

MySQL InnoDB 引擎使用 redo log(重做日志) 保证事务的持久性，使用 undo log(回滚日志) 来保证事务的原子性。

MySQL 数据库的数据备份、主备、主主、主从都离不开 binlog，需要依靠 binlog 来同步数据，保证数据一致性。

== 和 equals的区别

• 对于基本数据类型来说，== 比较的是值。
• 对于引用数据类型来说，== 比较的是对象的内存地址。

equals() 不能用于判断基本数据类型的变量，只能用来判断两个对象是否相等。equals()方法存在于Object类中，而Object类是所有类的直接或间接父类，因此所有的类都有equals()方法。

equals() 方法存在两种使用情况：

• 类没有重写 equals()方法：通过equals()比较该类的两个对象时，等价于通过“==”比较这两个对象，使用的默认是 Object类equals()方法。
• 类重写了 equals()方法：一般我们都重写 equals()方法来比较两个对象中的属性是否相等；若它们的属性相等，则返回 true(即，认为这两个对象相等)。

为什么重写 equals() 时必须重写 hashCode() 方法？

因为两个相等的对象的 hashCode 值必须是相等。也就是说如果 equals 方法判断两个对象是相等的，那这两个对象的 hashCode 值也要相等。

如果重写 equals() 时没有重写 hashCode() 方法的话就可能会导致 equals 方法判断是相等的两个对象，hashCode 值却不相等。

索引是怎么使用？失效时机？

索引是一种用于加速数据库表中数据检索的结构。它类似于书籍中的目录，通过对数据的关键列建立索引，可以快速定位所需的数据行，而无需全表扫描。

类型：

• B-Tree 索引：最常见的索引类型，适用于大多数查询操作。
• Hash 索引：基于哈希表，适用于精确匹配查询。
• Full-Text 索引：用于全文搜索。
• R-Tree 索引：用于空间数据类型（如 GIS 数据）的查询。

优点：

• 使用索引可以大大加快数据的检索速度（大大减少检索的数据量）, 减少 IO 次数，这也是创建索引的最主要的原因。
• 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。

缺点：

• 创建索引和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态的修改，会降低 SQL 执行效率。
• 索引需要使用物理文件存储，也会耗费一定空间。

但是，使用索引一定能提高查询性能吗?

大多数情况下，索引查询都是比全表扫描要快的。但是如果数据库的数据量不大，那么使用索引也不一定能够带来很大提升。

索引失效场景

创建了组合索引，但查询条件未遵守最左匹配原则;

在索引列上进行计算、函数、类型转换等操作;

以 % 开头的 LIKE 查询比如 LIKE '%abc';;

查询条件中使用 OR，且 OR 的前后条件中有一个列没有索引，涉及的索引都不会被使用到;

IN 的取值范围较大时会导致索引失效，走全表扫描(NOT IN 和 IN 的失效场景相同);

发生隐式转换；

1

SELECT * FROM users WHERE username = 123;  -- 假设 username 是字符串类型，索引失效

查询条件使用 != 或 <>

使用 IS NULL 或 IS NOT NULL

排序操作（ORDER BY）中混合使用 ASC 和 DESC

表中的数据量很少

mysql中的锁

乐观锁与悲观锁

乐观锁 基于乐观的假设，认为多个事务并发修改数据时不会发生冲突。它通常不直接使用数据库的锁机制，而是通过版本号或时间戳等机制来实现。

在数据库表中添加一个 version 字段，表示数据的版本。当事务读取数据时，也会读取这个 version。在提交更新时，事务会检查当前数据库中的 version 是否与自己读取时的一致。如果一致，才会更新数据，并将 version 加1；如果不一致，表示有其他事务已经修改了该数据，当前事务需要进行重试或处理冲突。

悲观锁 采取悲观的态度，假设并发修改数据时会发生冲突。因此，在操作数据之前，会先锁住数据，以防止其他事务对其进行修改。悲观锁通常通过数据库的锁机制来实现。

使用 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 语句显式地对数据行进行加锁。在使用 FOR UPDATE 时，该行数据会被锁住，其他事务在同一行上执行 SELECT FOR UPDATE 或更新操作时会被阻塞，直到锁被释放。

在事务中执行更新、删除操作时，MySQL 会自动为相关数据行加锁。

表级锁和行级锁

表级锁： MySQL 中锁定粒度最大的一种锁（全局锁除外），是针对非索引字段加的锁，对当前操作的整张表加锁，实现简单，资源消耗也比较少，加锁快，不会出现死锁。不过，触发锁冲突的概率最高，高并发下效率极低。表级锁和存储引擎无关，MyISAM 和 InnoDB 引擎都支持表级锁。

行级锁： MySQL 中锁定粒度最小的一种锁，是 针对索引字段加的锁 ，只针对当前操作的行记录进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小，并发度高，但加锁的开销也最大，加锁慢，会出现死锁。行级锁和存储引擎有关，是在存储引擎层面实现的。

InnoDB 的行锁是针对索引字段加的锁，表级锁是针对非索引字段加的锁。当我们执行 UPDATE、DELETE 语句时，如果 WHERE条件中字段没有命中唯一索引或者索引失效的话，就会导致扫描全表对表中的所有行记录进行加锁。这个在我们日常工作开发中经常会遇到，一定要多多注意！！

行锁有哪些

记录锁（Record Lock）：也被称为记录锁，属于单个行记录上的锁。

间隙锁（Gap Lock）：锁定一个范围，不包括记录本身。

临键锁（Next-Key Lock）：Record Lock+Gap Lock，锁定一个范围，包含记录本身，主要目的是为了解决幻读问题（MySQL 事务部分提到过）。记录锁只能锁住已经存在的记录，为了避免插入新记录，需要依赖间隙锁。

在 InnoDB 默认的隔离级别 REPEATABLE-READ 下，行锁默认使用的是 Next-Key Lock。但是，如果操作的索引是唯一索引或主键，InnoDB 会对 Next-Key Lock 进行优化，将其降级为 Record Lock，即仅锁住索引本身，而不是范围。

共享锁和排他锁

不论是表级锁还是行级锁，都存在共享锁（Share Lock，S 锁）和排他锁（Exclusive Lock，X 锁）这两类：

• 共享锁（S 锁）：又称读锁，事务在读取记录的时候获取共享锁，允许多个事务同时获取（锁兼容）。
• 排他锁（X 锁）：又称写锁/独占锁，事务在修改记录的时候获取排他锁，不允许多个事务同时获取。如果一个记录已经被加了排他锁，那其他事务不能再对这条事务加任何类型的锁（锁不兼容）。

由于 MVCC 的存在，对于一般的 SELECT 语句，InnoDB 不会加任何锁。不过， 你可以通过以下语句显式加共享锁或排他锁。

1
2
3
4
5
6

# 共享锁 可以在 MySQL 5.7 和 MySQL 8.0 中使用
SELECT ... LOCK IN SHARE MODE;
# 共享锁 可以在 MySQL 8.0 中使用
SELECT ... FOR SHARE;
# 排他锁
SELECT ... FOR UPDATE;

意向锁

如果需要用到表锁的话，如何判断表中的记录没有行锁呢，一行一行遍历肯定是不行，性能太差。我们需要用到一个叫做意向锁的东东来快速判断是否可以对某个表使用表锁。

意向锁是表级锁，共有两种：

• 意向共享锁（Intention Shared Lock，IS 锁）：事务有意向对表中的某些记录加共享锁（S 锁），加共享锁前必须先取得该表的 IS 锁。
• 意向排他锁（Intention Exclusive Lock，IX 锁）：事务有意向对表中的某些记录加排他锁（X 锁），加排他锁之前必须先取得该表的 IX 锁。

意向锁是由数据引擎自己维护的，用户无法手动操作意向锁，在为数据行加共享/排他锁之前，InooDB 会先获取该数据行所在在数据表的对应意向锁。

意向锁之间是互相兼容的。

意向锁和共享锁和排它锁互斥（这里指的是表级别的共享锁和排他锁，意向锁不会与行级的共享锁和排他锁互斥）。

快照读和当前读

快照读（一致性非锁定读）就是单纯的 SELECT 语句，但不包括下面这两类 SELECT 语句。

1
2
3
4
5

SELECT ... FOR UPDATE
# 共享锁 可以在 MySQL 5.7 和 MySQL 8.0 中使用
SELECT ... LOCK IN SHARE MODE;
# 共享锁 可以在 MySQL 8.0 中使用
SELECT ... FOR SHARE;

快照即记录的历史版本，每行记录可能存在多个历史版本（多版本技术）。

快照读的情况下，如果读取的记录正在执行 UPDATE/DELETE 操作，读取操作不会因此去等待记录上 X 锁的释放，而是会去读取行的一个快照。

只有在事务隔离级别 RC(读取已提交) 和 RR（可重读）下，InnoDB 才会使用一致性非锁定读：

• 在 RC 级别下，对于快照数据，一致性非锁定读总是读取被锁定行的最新一份快照数据。
• 在 RR 级别下，对于快照数据，一致性非锁定读总是读取本事务开始时的行数据版本。

快照读比较适合对于数据一致性要求不是特别高且追求极致性能的业务场景。

当前读 （一致性锁定读）就是给行记录加 X 锁或 S 锁。

当前读的一些常见 SQL 语句类型如下：

1
2
3
4
5
6
7
8
9
10

# 对读的记录加一个X锁
SELECT...FOR UPDATE
# 对读的记录加一个S锁
SELECT...LOCK IN SHARE MODE
# 对读的记录加一个S锁
SELECT...FOR SHARE
# 对修改的记录加一个X锁
INSERT...
UPDATE...
DELETE...

自增锁

关系型数据库设计表的时候，通常会有一列作为自增主键。InnoDB 中的自增主键会涉及一种比较特殊的表级锁— 自增锁（AUTO-INC Locks） 。

更准确点来说，不仅仅是自增主键，AUTO_INCREMENT的列都会涉及到自增锁，毕竟非主键也可以设置自增长。

如果一个事务正在插入数据到有自增列的表时，会先获取自增锁，拿不到就可能会被阻塞住。这里的阻塞行为只是自增锁行为的其中一种，可以理解为自增锁就是一个接口，其具体的实现有多种。具体的配置项为 innodb_autoinc_lock_mode （MySQL 5.1.22 引入），可以选择的值如下

交错模式下，所有的“INSERT-LIKE”语句（所有的插入语句，包括：INSERT、REPLACE、INSERT…SELECT、REPLACE…SELECT、LOAD DATA等）都不使用表级锁，使用的是轻量级互斥锁实现，多条插入语句可以并发执行，速度更快，扩展性也更好。

不过，如果你的 MySQL 数据库有主从同步需求并且 Binlog 存储格式为 Statement 的话，不要将 InnoDB 自增锁模式设置为交叉模式，不然会有数据不一致性问题。这是因为并发情况下插入语句的执行顺序就无法得到保障。

zookeeper为什么可以实现强一致性的分布式锁

ZooKeeper 提供了强顺序一致性，这意味着客户端对同一个 ZooKeeper 节点的更新操作是按照顺序执行的，并且所有客户端都能看到相同的更新顺序。通过这种顺序一致性，ZooKeeper 可以确保所有客户端在同一时间看到的数据状态是一致的。

ZooKeeper 提供了临时顺序节点的功能。客户端在创建一个临时顺序节点时，会获得一个全局唯一且递增的序号，这个节点在客户端会话结束时（比如客户端崩溃或与 ZooKeeper 的连接断开）会自动删除。利用这一特性，可以实现分布式锁。

避免死锁与竞争

• 自动删除节点：由于使用的是临时顺序节点，当客户端因故障与 ZooKeeper 断开连接时，ZooKeeper 会自动删除该客户端创建的节点，避免锁资源被永久占用，从而防止死锁的发生。
• 竞争公平性：因为所有节点都是按顺序创建的，锁的获取是基于节点的顺序号，先创建的节点先获得锁，这保证了锁的公平性，不会因为客户端的网络延迟等原因导致锁的争夺不公平。

ZooKeeper 使用的是 Zab（ZooKeeper Atomic Broadcast）协议 作为其核心的分布式一致性算法。

Zab 协议在 ZooKeeper 中主要用于以下两个目的：

• Leader 选举：在 ZooKeeper 集群中选出一个主节点（Leader），其余节点作为从节点（Followers）。所有写请求都通过 Leader 处理，再由 Leader 将更新广播给 Followers。
• 原子广播（Atomic Broadcast）：确保所有节点以相同的顺序应用相同的更新，保持数据的一致性。

Zab 协议的核心流程

1. Leader 选举：当 ZooKeeper 集群启动或现任 Leader 出现故障时，Zab 协议会启动 Leader 选举过程。集群中的所有节点会根据各自的投票信息选出一个新的 Leader。选举过程中，节点会根据各自的 ZXID（事务 ID）来决定投票，ZXID 更大的节点具有更高的优先级。
2. 同步数据：当新的 Leader 被选出后，Leader 会与 Followers 同步数据，确保所有节点的状态一致。这通常涉及将 Followers 的数据状态更新到最新的事务版本。
3. 原子广播：在广播模式下，所有的写请求都被发送到 Leader 处理。Leader 将这些写请求封装成事务提案（Proposal），并将其以原子广播的方式发送给所有 Followers。所有 Followers 都必须对提案进行确认（Ack），一旦 Leader 收到了半数以上节点的确认，它就会将事务提交，并通知所有节点应用该事务。
4. 保证一致性：Zab 协议通过严格的顺序更新和多节点确认机制，确保即使在节点崩溃或网络分区等情况下，ZooKeeper 集群仍然能够保证数据的一致性和可用性。

缓存击穿，穿透，雪崩

缓存击穿

缓存击穿中，请求的 key 对应的是 热点数据 ，该数据 存在于数据库中，但不存在于缓存中（通常是因为缓存中的那份数据已经过期） 。这就可能会导致瞬时大量的请求直接打到了数据库上，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。

举个例子：秒杀进行过程中，缓存中的某个秒杀商品的数据突然过期，这就导致瞬时大量对该商品的请求直接落到数据库上，对数据库造成了巨大的压力。

永不过期（不推荐）：设置热点数据永不过期或者过期时间比较长。

提前预热（推荐）：针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。

加锁（看情况）：在缓存失效后，通过设置互斥锁确保只有一个请求去查询数据库并更新缓存。

缓存穿透

缓存穿透说简单点就是大量请求的 key 是不合理的，根本不存在于缓存中，也不存在于数据库中 。这就导致这些请求直接到了数据库上，根本没有经过缓存这一层，对数据库造成了巨大的压力，可能直接就被这么多请求弄宕机了。

解决方法如下

缓存无效 key

如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间，具体命令如下：SET key value EX 10086 。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。

布隆过滤器

布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们可以把它看作由二进制向量（或者说位数组）和一系列随机映射函数（哈希函数）两部分组成的数据结构。相比于我们平时常用的 List、Map、Set 等数据结构，它占用空间更少并且效率更高，但是缺点是其返回的结果是概率性的，而不是非常准确的。

具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。

接口限流

根据用户或者 IP 对接口进行限流，对于异常频繁的访问行为，还可以采取黑名单机制，例如将异常 IP 列入黑名单。

后面提到的缓存击穿和雪崩都可以配合接口限流来解决，毕竟这些问题的关键都是有很多请求落到了数据库上造成数据库压力过大。

缓存穿透和缓存击穿有什么区别

缓存穿透中，请求的 key 既不存在于缓存中，也不存在于数据库中。

缓存击穿中，请求的 key 对应的是 热点数据 ，该数据 存在于数据库中，但不存在于缓存中（通常是因为缓存中的那份数据已经过期）

缓存雪崩

缓存在同一时间大面积的失效，导致大量的请求都直接落到了数据库上，对数据库造成了巨大的压力。 这就好比雪崩一样，摧枯拉朽之势，数据库的压力可想而知，可能直接就被这么多请求弄宕机了。

有哪些解决办法？

针对 Redis 服务不可用的情况：

1. Redis 集群：采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。Redis Cluster 和 Redis Sentinel 是两种最常用的 Redis 集群实现方案，详细介绍可以参考：Redis 集群详解(付费)open in new window。
2. 多级缓存：设置多级缓存，例如本地缓存+Redis 缓存的二级缓存组合，当 Redis 缓存出现问题时，还可以从本地缓存中获取到部分数据。

针对大量缓存同时失效的情况：

1. 设置随机失效时间（可选）：为缓存设置随机的失效时间，例如在固定过期时间的基础上加上一个随机值，这样可以避免大量缓存同时到期，从而减少缓存雪崩的风险。
2. 提前预热（推荐）：针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。
3. 持久缓存策略（看情况）：虽然一般不推荐设置缓存永不过期，但对于某些关键性和变化不频繁的数据，可以考虑这种策略。

聚簇索引与非聚簇索引

聚簇索引（Clustered Index）即索引结构和数据一起存放的索引，并不是一种单独的索引类型。InnoDB 中的主键索引就属于聚簇索引。

在 MySQL 中，InnoDB 引擎的表的 .ibd文件就包含了该表的索引和数据，对于 InnoDB 引擎表来说，该表的索引(B+树)的每个非叶子节点存储索引，叶子节点存储索引和索引对应的数据。

优点：

• 查询速度非常快：聚簇索引的查询速度非常的快，因为整个 B+树本身就是一颗多叉平衡树，叶子节点也都是有序的，定位到索引的节点，就相当于定位到了数据。相比于非聚簇索引， 聚簇索引少了一次读取数据的 IO 操作。
• 对排序查找和范围查找优化：聚簇索引对于主键的排序查找和范围查找速度非常快。

缺点：

• 依赖于有序的数据：因为 B+树是多路平衡树，如果索引的数据不是有序的，那么就需要在插入时排序，如果数据是整型还好，否则类似于字符串或 UUID 这种又长又难比较的数据，插入或查找的速度肯定比较慢。
• 更新代价大：如果对索引列的数据被修改时，那么对应的索引也将会被修改，而且聚簇索引的叶子节点还存放着数据，修改代价肯定是较大的，所以对于主键索引来说，主键一般都是不可被修改的。

非聚簇索引(Non-Clustered Index)即索引结构和数据分开存放的索引，并不是一种单独的索引类型。二级索引(辅助索引)就属于非聚簇索引。MySQL 的 MyISAM 引擎，不管主键还是非主键，使用的都是非聚簇索引。

非聚簇索引的叶子节点并不一定存放数据的指针，因为二级索引的叶子节点就存放的是主键，根据主键再回表查数据。

优点：

更新代价比聚簇索引要小 。非聚簇索引的更新代价就没有聚簇索引那么大了，非聚簇索引的叶子节点是不存放数据的。

缺点：

• 依赖于有序的数据:跟聚簇索引一样，非聚簇索引也依赖于有序的数据
• 可能会二次查询(回表):这应该是非聚簇索引最大的缺点了。 当查到索引对应的指针或主键后，可能还需要根据指针或主键再到数据文件或表中查询。

非聚簇索引不一定回表查询。

用户准备使用 SQL 查询用户名，而用户名字段正好建立了索引。

1

SELECT name FROM table WHERE name='guang19';

那么这个索引的 key 本身就是 name，查到对应的 name 直接返回就行了，无需回表查询。

什么是回表

它描述了在使用非聚簇索引（或辅助索引）进行查询时，需要再通过主键索引（或聚簇索引）去获取完整的行数据的过程。

redis键过长会有什么影响？

懵了一下，故意刁难人吧，哪个正常人会把key弄得很长？

1. 内存占用增加

2. 网络带宽消耗增加

3. 查询性能下降。在 Redis 中，键的比较是通过逐字节比较的方式进行的，因此键越长，比较操作的时间就越长。在高并发和大量键的情况下，这种额外的比较时间会影响查询性能。

4. 持久化和数据加载时间增加

5. 键空间效率低。Redis 使用的是字典数据结构（hash table）来存储键值对，过长的键可能导致 hash 冲突的概率增加，进而影响 Redis 的哈希性能。

redis中hash结构有哪些使用场景

1. 存储用户信息。用户的基本信息（如用户名、邮箱、年龄等）可以通过哈希结构存储在一个键中:

1
2
3
4
5

user:1001 -> {
    "name": "Alice",
    "email": "alice@example.com",
    "age": "30"
}

2. 会话管理。例如存储session。

SpringCloud组件有哪些

• Spring Cloud Config
• Spring Cloud Netflix：Spring Cloud Netflix是对Netflix开发的一套分布式服务框架的封装，包括服务的发现和注册，负载均衡、断路器、REST客户端、请求路由等。它是Spring Cloud的一部分。包括 Eureka、Ribbon、Hystrix、Zuul、Gateway。
• Spring Cloud Gateway
• Spring Cloud OpenFeign
• Spring Cloud Sleuth： 分布式追踪工具，用于在微服务架构中跟踪请求的流转路径，支持与 Zipkin、Jaeger 等分布式追踪系统集成。
• Spring Cloud Bus：用于将消息总线连接到多个分布式系统的节点，通常与 Spring Cloud Config 结合使用，实现配置的动态刷新。

国内常用的SpringCloudAlibaba组件有：

• Nacos: 提供服务发现、配置管理、动态 DNS 和服务健康检查的功能。Nacos 是 Spring Cloud Alibaba 中的核心组件，用于替代 Spring Cloud Netflix 的 Eureka 和 Spring Cloud Config。
• Sentinel: 提供流量控制、熔断降级、系统负载保护等功能。Sentinel 是一个高可用保护的流量管理工具，能够对微服务进行全面的保护。
• RocketMQ: 分布式消息中间件，支持高吞吐量、低延迟和高可用的消息传递。Spring Cloud Alibaba 提供了对 RocketMQ 的集成，方便微服务之间的消息通信。
• Dubbo: 高性能的 RPC 框架，支持微服务间的远程调用。Dubbo 提供了服务治理、服务监控等功能，并与 Spring Cloud 集成，实现微服务的无缝对接。
• Seata: 分布式事务管理框架，支持微服务架构中的分布式事务，能够在多服务、多数据库的场景下保证事务的最终一致性。

在阿里云上商用的组件还有：

• Alibaba Cloud OSS: 阿里云的对象存储服务，提供大规模、高可用的云存储解决方案。Spring Cloud Alibaba 提供了与 OSS 的集成，使开发者能够方便地在微服务中使用对象存储。
• Alibaba Cloud SMS: 阿里云的短信服务，支持通过 API 发送短信验证码、通知等。Spring Cloud Alibaba 集成了短信服务，方便在微服务中使用短信功能。
• Alibaba Cloud ACM (Application Configuration Management): 应用配置管理服务，类似于 Nacos 的配置管理功能，但更加侧重于企业级应用的配置管理。Spring Cloud Alibaba 集成了 ACM，提供了配置管理的高级功能。
• Alibaba Cloud SchedulerX: 分布式任务调度平台，支持高可用、高并发的任务调度。SchedulerX 可以用于定时任务、分布式任务和调度任务的管理。
• Alibaba Cloud MNS (Message Notification Service): 消息通知服务，支持大规模的异步消息通知。Spring Cloud Alibaba 提供了对 MNS 的集成，使开发者能够轻松实现消息通知功能。
• Alibaba Cloud ARMS (Application Real-Time Monitoring Service): 应用实时监控服务，提供了对分布式系统的全方位监控，包括性能监控、日志分析、报警等。Spring Cloud Alibaba 集成了 ARMS，支持对微服务的实时监控。

一周没写复盘了。上周主要是滴滴的一面，一个小公司的一面，还有个网易的线下面试。网易那个其实都在问简历的东西，方向不是很匹配，大概是凉了。今天是小公司的二面，可能面试官觉得之前做的东西不是业务开发，所以感觉机会也小。这次把两次面试一起复盘了。

复盘

TCP和UDP

UDP 一般用于即时通信，比如：语音、 视频、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。

TCP 用于对传输准确性要求特别高的场景，比如文件传输、发送和接收邮件、远程登录等等。

ES作用？为什么不用mysql？mysql模糊查询？

ElasticSearch 是一个开源的 分布式、RESTful 搜索和分析引擎，可以用来解决使用数据库进行模糊搜索时存在的性能问题，适用于所有类型的数据，包括文本、数字、地理空间、结构化和非结构化数据。

Elasticsearch 使用倒排索引来支持快速的全文搜索和复杂的查询操作。这使得 ES 能够高效地处理大量的非结构化数据（如日志）。ES 能够对多个字段进行模糊搜索、词语匹配、词干提取等复杂查询，并且性能优越。

MySQL 的主要索引结构是 B-Tree 索引，适合处理结构化数据和简单查询。但对于全文搜索、复杂查询和模糊匹配，性能较差。

虽然 MySQL 也支持全文索引（如 InnoDB 和 MyISAM 引擎），但其搜索功能和性能不如 Elasticsearch 强大，特别是在处理大量日志数据时。

mysql模糊查询有三种情况：

前缀匹配 (LIKE 'keyword%')：查找以 keyword 开头的记录，这种情况下如果 column_name 有索引，MySQL 可以有效利用索引。

后缀匹配 (LIKE '%keyword')：查找以 keyword 结尾的记录，通常索引无法生效。

全匹配 (LIKE '%keyword%')：查找包含 keyword 的记录，索引也通常无法生效。

对于 MySQL 的 InnoDB 或 MyISAM 引擎，如果要进行更高效的模糊查询，尤其是针对大文本数据，可以使用全文索引。全文索引适用于自然语言文本的查找，但它主要适用于针对整词的搜索，而不是部分匹配。

1

SELECT * FROM my_table WHERE MATCH(column_name) AGAINST('keyword');

字典树，KMP，AC自动机

聊到mysql搜索的时候面试官突然说到这个，好久了，这里复习一下。

字典树（Trie），也称为前缀树或单词查找树，是一种用于存储字符串集的数据结构，特别适合处理字符串前缀相关的问题。字典树的结构类似于一棵多叉树，每个节点代表字符串中的一个字符，通过节点之间的链接表示字符串的前缀关系。

字典树的基本特性

1. 根节点不包含字符，它仅用于表示一个空字符串。
2. 每个节点都表示一个字符，通过路径从根节点到某个节点，可以组成一个字符串。
3. 每个节点的所有子节点表示不同的字符，即所有子节点不重复。
4. 路径上的每个节点都对应一个前缀，从根节点到某个节点的路径表示一个字符串的前缀或完整字符串。

假设我们有一组单词集：["cat", "cap", "bat", "bad"]，它的字典树可能是这样的：

1
2
3
4
5
6
7

     root
     /  \
    c    b
   / \   / \
  a   a a   a
 /   /   \   \
t   p     d   t

字典树的优缺点

• 优点：
  • 高效的前缀查找：对于前缀匹配和字符串查找，字典树可以在 O(m) 时间复杂度内完成操作，其中 m 是字符串的长度。
  • 结构清晰：字典树的结构非常直观，特别适合处理字符串。
• 缺点：
  • 空间消耗大：由于每个节点都需要存储多个子节点的引用，字典树的空间消耗较大，尤其在字符集较大的情况下。
  • 不适合处理变长字符串：对于非常长的字符串，字典树的深度会很大，导致操作效率下降。

KMP

Knuth-Morris-Pratt 算法，用于在一个字符串中快速查找另一个字符串（即模式匹配问题）。查找单个模式的时间复杂度是 O(n)，其中 n 是主字符串的长度。

KMP算法：主要用于单个模式字符串在一个主字符串中的查找，适用于模式匹配问题。

字典树：用于存储和快速查询多个字符串，特别适合处理前缀查询、多模式匹配、自动补全等问题。

AC自动机

AC自动机，全称 Aho-Corasick 自动机，是一种多模式字符串匹配算法。它结合了 字典树（Trie） 和 KMP算法 的思想，用于在一个文本中同时查找多个模式字符串。AC自动机在网络安全、文本检索、DNA序列分析等领域有广泛应用。

AC自动机的构建和使用分为以下几个步骤：

1. 构建字典树（Trie）把所有模式字符串插入到字典树中，构建一棵多叉树。
2. 构建失败指针（Failure Pointer）在字典树的基础上，构建每个节点的失败指针。失败指针指向当前匹配失败时，应该转移到的下一个状态（即节点）。如果某个状态下的字符匹配失败，则通过失败指针跳转到另一个状态继续匹配，直到匹配成功或回到根节点。
3. 匹配过程。在文本中进行匹配时，从根节点开始，逐个字符遍历文本。如果当前字符匹配成功，则进入下一个状态。如果匹配失败，则通过失败指针进行状态转移，继续匹配。

说实话这次面试官是个算法工程师，所以对算法比较在行。说实话我对算法不是很熟悉。

HTTP和RPC

HTTP （超文本传输协议）是一种应用层协议。

使用场景：

• Web 浏览器与服务器之间的通信：加载网页、提交表单、下载文件等。
• RESTful API：使用 HTTP 协议进行跨平台、跨语言的服务调用。

RPC 是一种分布式计算协议，它使得一个程序可以像调用本地函数一样，调用位于远程服务器上的函数或过程。RPC 的目的是隐藏网络通信的细节，让开发者可以专注于业务逻辑。

HTTP 更适合于 Web 应用和简单的 API 调用，而 RPC 更适用于复杂的分布式系统和微服务架构。

redis作用

这个不再多说了。之前复习过好几次了。

其他问题都是项目介绍，就不展开了。

MongoDB用过吗？存什么数据？

MongoDB 是一个基于 分布式文件存储 的开源 NoSQL 数据库系统，由 C++ 编写的。MongoDB 提供了 面向文档 的存储方式，操作起来比较简单和容易，支持“无模式”的数据建模，可以存储比较复杂的数据类型，是一款非常流行的 文档类型数据库 。

适合存储的数据类型

• 非结构化数据：MongoDB 使用 BSON（Binary JSON）格式来存储数据，能够处理复杂的嵌套结构和多样化的数据类型，包括文档、数组、嵌套对象等。
• 动态模式的数据：对于数据模型经常变化的应用，MongoDB 允许文档之间的字段不一致，使得模式可以灵活调整。
• 大规模的数据：MongoDB 支持水平扩展（sharding），能够处理大规模的数据存储需求。

例如存储和管理不同类型的内容（如文章、评论、用户信息）以及内容的元数据。

灵活的数据模型：不同的内容可能有不同的字段和结构，如文章有标题、正文、作者等字段，评论有评论者、内容、时间等字段。MongoDB 的文档模型允许每个内容类型有不同的结构。

嵌套文档：可以在一个文档中嵌套评论，避免了复杂的联接操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

{
  "_id": "article_123",
  "title": "Introduction to MongoDB",
  "author": "John Doe",
  "content": "MongoDB is a NoSQL database...",
  "comments": [
    {
      "user": "Alice",
      "comment": "Great article!",
      "date": "2024-08-10"
    },
    {
      "user": "Bob",
      "comment": "Very informative.",
      "date": "2024-08-11"
    }
  ]
}

又比如存储和处理来自大量设备的数据，如传感器数据、设备状态和日志。

高吞吐量和可扩展性：支持大规模数据写入，适合物联网场景中的实时数据采集。

时间序列数据：能够处理时间序列数据，支持高效的插入和查询操作。

mysql数据结构

BTree 索引：MySQL 里默认和最常用的索引类型。只有叶子节点存储 value，非叶子节点只有指针和 key。存储引擎 MyISAM 和 InnoDB 实现 BTree 索引都是使用 B+Tree，但二者实现方式不一样（前面已经介绍了）。

哈希索引：类似键值对的形式，一次即可定位。

RTree 索引：一般不会使用，仅支持 geometry 数据类型，优势在于范围查找，效率较低，通常使用搜索引擎如 ElasticSearch 代替。

全文索引：对文本的内容进行分词，进行搜索。目前只有 CHAR、VARCHAR ，TEXT 列上可以创建全文索引。一般不会使用，效率较低，通常使用搜索引擎如 ElasticSearch 代替。

B 树& B+树两者有何异同呢？

• B 树的所有节点既存放键(key) 也存放数据(data)，而 B+树只有叶子节点存放 key 和 data，其他内节点只存放 key。
• B 树的叶子节点都是独立的;B+树的叶子节点有一条引用链指向与它相邻的叶子节点。
• B 树的检索的过程相当于对范围内的每个节点的关键字做二分查找，可能还没有到达叶子节点，检索就结束了。而 B+树的检索效率就很稳定了，任何查找都是从根节点到叶子节点的过程，叶子节点的顺序检索很明显。
• 在 B 树中进行范围查询时，首先找到要查找的下限，然后对 B 树进行中序遍历，直到找到查找的上限；而 B+树的范围查询，只需要对链表进行遍历即可。

B+树与 B 树相比，具备更少的 IO 次数、更稳定的查询效率和更适于范围查询这些优势。

B+树为什么快

1. 树的高度较低。B+树是一种自平衡的多路查找树，所有的叶子节点都在同一层。这意味着从根节点到任一叶子节点的路径长度（即树的高度）是相同的。
2. 顺序存储叶子节点。B+树的所有数据都存储在叶子节点中，且所有叶子节点通过指针连接在一起形成一个有序链表。当需要进行范围查询（如查找某个区间内的所有数据）时，B+树可以从找到的起始叶子节点开始，顺序扫描后续的叶子节点，大大提高了查询效率。
3. 分裂与合并减少磁盘I/O。在B+树中，节点分裂和合并的操作次数相对较少，因为每个节点可以包含多个元素。当插入或删除元素时，不会频繁触发树的重平衡操作，这减少了磁盘I/O操作的频率。由于树的高度较低，搜索过程中的磁盘I/O次数较少，而磁盘I/O通常是数据库系统中的瓶颈，因此 B+ 树能够显著提高查找速度。
4. 所有键值在叶子节点上。在 B+ 树中，所有实际数据（键值对）都存储在叶子节点上，中间节点只存储键值用于指引搜索路径。这意味着每次查找最终都会访问到叶子节点，避免了不必要的键值访问，简化了搜索路径。

前缀查找与全文检索

前缀查找和全文检索是两种不同的查询方式。前缀查找通常是基于B+树索引（如 BTREE 索引）的查询方式，通过匹配字符串的前缀来进行快速定位。例如，WHERE column LIKE 'abc%' 这样的查询就是典型的前缀查找。

全文检索（Full-Text Search）是一种基于全文索引的查询方式，专门用于查找大文本中的关键词。MySQL 提供的 FULLTEXT 索引可以支持自然语言模式和布尔模式下的全文检索。

前缀查找通常比全文检索快，因为它只需在索引中定位前缀即可，而全文检索需要更复杂的计算和匹配操作。不过，这也取决于数据的规模和具体的查询条件。

全文检索更灵活，可以查找文本中的任意位置，而前缀查找只能匹配字符串的开头部分。

如果你只需要匹配字符串的前缀（如用户名查找），前缀查找更合适且更快；但如果你需要在大文本中查找关键词（如文章搜索），全文检索则更适合，尽管速度可能略慢。

mysql调优

这个其实需要具体问题具体分析，前面也有一些复盘提过这个。

Redis线程模型

对于读写命令来说，Redis 一直是单线程模型。不过，在 Redis 4.0 版本之后引入了多线程来执行一些大键值对的异步删除操作， Redis 6.0 版本之后引入了多线程来处理网络请求（提高网络 IO 读写性能）。

Redis 基于 Reactor 模式设计开发了一套高效的事件处理模型 （Netty 的线程模型也基于 Reactor 模式，Reactor 模式不愧是高性能 IO 的基石），这套事件处理模型对应的是 Redis 中的文件事件处理器（file event handler）。由于文件事件处理器（file event handler）是单线程方式运行的，所以我们一般都说 Redis 是单线程模型。

既然是单线程，那怎么监听大量的客户端连接呢？

Redis 通过 IO 多路复用程序 来监听来自客户端的大量连接（或者说是监听多个 socket），它会将感兴趣的事件及类型（读、写）注册到内核中并监听每个事件是否发生。

这样的好处非常明显：I/O 多路复用技术的使用让 Redis 不需要额外创建多余的线程来监听客户端的大量连接，降低了资源的消耗（和 NIO 中的 Selector 组件很像）。

虽然说 Redis 是单线程模型，但实际上，Redis 在 4.0 之后的版本中就已经加入了对多线程的支持。

不过，Redis 4.0 增加的多线程主要是针对一些大键值对的删除操作的命令，使用这些命令就会使用主线程之外的其他线程来“异步处理”，从而减少对主线程的影响。

为此，Redis 4.0 之后新增了几个异步命令：

• UNLINK：可以看作是 DEL 命令的异步版本。
• FLUSHALL ASYNC：用于清空所有数据库的所有键，不限于当前 SELECT 的数据库。
• FLUSHDB ASYNC：用于清空当前 SELECT 数据库中的所有键。

Redis6.0 引入多线程主要是为了提高网络 IO 读写性能，因为这个算是 Redis 中的一个性能瓶颈（Redis 的瓶颈主要受限于内存和网络）。

虽然，Redis6.0 引入了多线程，但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了，执行命令仍然是单线程顺序执行。

Redis如何做主从同步

1. 当从节点启动并配置为从主节点复制数据时，从节点会向主节点发送 PSYNC 命令，表示希望与主节点同步。
2. 如果从节点是第一次与主节点同步，主节点会执行全量同步。如果从节点曾经同步过，但与主节点的连接中断了一段时间，主节点会尝试进行增量同步（如果从节点的复制偏移量与主节点匹配）。
3. 主节点生成当前内存数据的快照（RDB 文件），并将该快照发送给从节点。从节点接收快照文件并将其加载到内存中，完成数据同步。在快照传输的同时，主节点会继续记录新的写操作，并在快照传输完成后将这些增量操作也发送给从节点。
4. 当主节点判断从节点可以进行增量同步时，主节点只将从节点缺失的那部分命令发送给从节点。从节点执行这些命令，从而使自身的数据与主节点保持一致。
5. 从节点与主节点保持长连接，主节点会实时将所有写命令传播给从节点，使得从节点的数据保持与主节点同步。

mq的选型

首先要明确业务需求，包括但不限于以下几点：

消息的吞吐量：预估系统每秒钟需要处理的消息数量。
消息的延迟要求：消息传递的实时性要求如何，是否可以容忍延迟。
消息持久化：是否需要消息的持久化存储，以便系统故障时能够恢复。
消息的顺序性：消息是否需要保证严格的顺序性。
消息的可靠性：是否需要确保消息不丢失、不重复。
可扩展性：系统未来可能需要的扩展能力。
与现有技术栈的兼容性：是否与现有的技术栈兼容，或者团队是否擅长使用。

Apache Kafka

特点：

• 高吞吐量，支持大规模数据传输。
• 适合处理流式数据，如日志、事件数据的实时处理。
• 数据持久化存储，支持消息重放。
• 强大的分区机制，支持消息的水平扩展。
• 有时会存在消息延迟，尤其是在高吞吐场景下。

适用场景：

• 实时数据处理、日志收集和分析、事件驱动架构、流处理等。
• 大数据相关的应用场景。

RabbitMQ

特点：

• 支持丰富的消息路由规则（如发布/订阅、点对点、路由键）。
• 高可靠性，支持消息确认机制、持久化、镜像队列等。
• 支持复杂的消息路由和协议（如 AMQP、STOMP、MQTT）。
• 吞吐量较 Kafka 低，但延迟较低。

适用场景：

• 金融系统、订单处理、需要复杂路由逻辑的场景。
• 高可靠性、高一致性要求的应用。

kafka如何实现负载均衡

这个我可能理解错了，我以为说的是部署如何实现负载均衡。其实应该是使用上的消息负载均衡。

主题（Topic）与分区（Partition）

• 分区的概念：Kafka 将每个主题（Topic）分成多个分区（Partition），每个分区都是一个有序的消息队列。消息会被分发到不同的分区中，每个分区只能被一个消费者组中的一个消费者消费。
• 负载均衡的基础：分区是实现负载均衡的基本单位。Kafka 通过将消息分配到不同的分区来实现消息的分布，而消费者组内的消费者则通过消费不同的分区来实现负载均衡。

生产者端的负载均衡

• 分区选择策略：生产者在发送消息时，需要决定消息发送到哪个分区。Kafka 提供了几种分区选择策略：
  • 轮询策略（Round-Robin）：消息被轮询地发送到每一个分区。这种方式简单而均匀。
  • 基于键的分区策略：如果消息携带了一个键，Kafka 会根据这个键的哈希值来选择分区。这样可以保证相同键的消息总是被发送到相同的分区，实现消息的有序性。
  • 自定义分区器：用户可以实现自己的分区器逻辑，控制消息如何分布到不同的分区。

消费者端的负载均衡

• 消费者组：Kafka 通过消费者组实现消费负载的自动均衡。每个消费者组由多个消费者实例组成，每个消费者实例负责消费一部分分区。
  • 消费者组的分区分配：Kafka 会自动将分区分配给消费者组中的消费者。默认的分配策略是均匀分配（Range Assignor）或轮询分配（RoundRobin Assignor）。如果消费者的数量发生变化（如新消费者加入或消费者退出），Kafka 会重新平衡分区分配，以确保每个消费者分配到的分区数量大致相等。
• 再平衡（Rebalance）：当消费者组中的消费者发生变化时（如新增消费者、消费者故障退出等），Kafka 会触发再平衡操作。再平衡过程会重新分配分区，以确保新的消费者组中的每个消费者都能公平地消费分区。再平衡过程中，消费者可能会暂停消费一段时间，直到新的分配完成。

kafka场景题

同一个topic，两个不同的消费者组，一个消费到5，第二个消费者组没有消费者，此时第二个消费者组进来一个消费者，此时应该消费什么？

没遇到过这种场景，蒙了一下，还蒙错了。不同消费者组其实是相互独立的。

不同消费者组的消费行为

• 相互独立：不同的消费者组是相互独立的，每个消费者组都会消费主题中的所有消息。也就是说，Kafka 会为每个消费者组维护独立的消费偏移量（offset），每个消费者组会从自己的偏移量开始消费消息。
• 重复消费：由于不同的消费者组独立消费消息，每个消费者组中的消费者实例都会消费主题中的全部消息。因此，同一个主题的不同消费者组会重复消费这些消息。

假设有一个主题 TopicA，它有 2 个分区，存在两个消费者组 Group1 和 Group2，每个消费者组中各有 2 个消费者实例。

• Group1 的两个消费者实例分别消费 TopicA 的两个分区中的消息。
• Group2 的两个消费者实例也会分别消费 TopicA 的两个分区中的消息。

算法1：topK问题

之前写过文章。就回答了三种算法。

排序

快排时间复杂度O(nlogn)

堆

使用一个大小为 K 的最小堆来维护当前遇到的前 K 个最大元素。

时间复杂度O(N log K)。其中 N 是元素的总数，K 是需要找出的最大元素数量。

快速选择法

基于快速排序的思想，使用分治法找到前 K 个元素。使用快速排序的分区（partition）方法，每次将集合划分成两部分，一部分比基准元素小，另一部分比基准元素大。判断基准元素的位置是否为第 K 大元素的位置，如果是，则前 K 个元素已经找到，否则继续递归处理相应的部分。

平均 O(N)，最坏 O(N^2)，平均情况下，快速选择法可以在线性时间内找到前 K 个元素，但在极端情况下，时间复杂度会退化为 O(N^2)。

桶排序法

将元素分到不同的桶中，根据需要的 K 值只处理最靠近的几个桶。

1. 确定桶的数量和范围。

2. 将元素分配到相应的桶中。

3. 对包含最大元素的桶进行排序，然后找出前 K 大的元素。

O(N)（分配到桶的操作）+ O(K log K)（在目标桶中排序）。

算法2：两个栈实现队列

主要思路：

• 将元素推入栈 stack1 中；
• 当需要出队列时，如果 stack2 为空，就将 stack1 中的所有元素逐个弹出，并推入 stack2，这样 stack2 中的元素顺序就是先进先出的顺序；
• 从 stack2 中弹出的元素就是队列的出队元素。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

import java.util.Stack;

public class MyQueue {
    private Stack<Integer> stack1;
    private Stack<Integer> stack2;

    public MyQueue() {
        stack1 = new Stack<>();
        stack2 = new Stack<>();
    }

    // 入队操作
    public void push(int x) {
        stack1.push(x);
    }

    // 出队操作
    public int pop() {
        if (stack2.isEmpty()) {
            while (!stack1.isEmpty()) {
                stack2.push(stack1.pop());
            }
        }
        return stack2.pop();
    }

    // 获取队列头部元素
    public int peek() {
        if (stack2.isEmpty()) {
            while (!stack1.isEmpty()) {
                stack2.push(stack1.pop());
            }
        }
        return stack2.peek();
    }

    // 判断队列是否为空
    public boolean empty() {
        return stack1.isEmpty() && stack2.isEmpty();
    }
}

面试的时候查了一下，结果又被csdn坑了，说要有一个额外变量记录最后一个元素。其实不需要的。

后话

说实话，有点麻木了。今天面试感觉也一般。不知道路在何方，感觉做的东西太小众了，然后会的东西太杂。导致其实很多东西没那么专精，但咋说呢，我觉得我应该还算可以吧。但就是没有啥收获。也许我该把项目经历改改。

就挺离谱的。环境好像真的一般般，都在内卷，面试候选人贼多，要选上也挺难的。

然后现在是越来越没动力了，一座在电脑前打开文档就犯困。

滴滴面试，面试官人很亲切。除了netty相关，其他都回答的七七八八，奈何人家就是用netty去做业务的，估计也是凉凉。

复盘

分布式锁场景?怎么实现

复盘过好多次了，就是redis去实现。

场景：

分布式锁是一种用于在分布式系统中协调对共享资源访问的技术，确保在多个节点同时访问某一资源时不会出现竞争和数据不一致问题。

分布式缓存一致性：当多个应用实例需要更新同一个缓存数据时，使用分布式锁可以确保只有一个实例可以进行更新操作，避免缓存不一致问题。

任务调度：在分布式任务调度系统中，为了防止同一个任务被多个节点重复执行，可以使用分布式锁来确保任务只会被一个节点执行。

限流控制：在高并发系统中，使用分布式锁可以限制同时处理的请求数量，避免系统过载。

分布式事务：在分布式事务中，使用分布式锁可以确保多个节点在执行跨数据库或跨服务的事务时，能够按照预期的顺序进行，避免数据不一致。

资源协调：在分布式系统中，多个节点可能需要访问共享资源（如文件、数据库记录等）。使用分布式锁可以确保每次只有一个节点能访问这些资源，避免竞争条件。

锁的自动续期

watchdog大部分回答出来了，后续再复习下。

redisson中如何解决主从同步问题

在使用 Redisson 实现分布式锁时，如果 Redis 处于主从模式（master-slave replication），可能会遇到主从同步问题。主从同步问题主要体现在以下几个方面：

1. 主节点崩溃和故障转移：当主节点崩溃时，从节点会接管成为新的主节点。在这个过程中，可能会出现锁状态丢失或不一致的问题。
2. 数据复制延迟：主节点和从节点之间的数据复制存在延迟，在这种情况下，从节点上的锁状态可能会滞后，导致数据不一致。

redLock

其实就是类似 redLock，通过将所有节点视为主节点。

Redlock 需要部署 N （N >= 2n+1）个独立的 Redis 实例，且实例之间没有任何的联系。也就是说，只要一半以上的 Redis 实例加锁成功，那么 Redlock 依然可以正常运行。

使用独立实例是为了避免 Redis 异步复制导致锁丢失。

Redlock 加锁失败有两种情况：

• 加锁成功的实例数量未超过半数。
• 加锁过程花费时间超过锁的有效时间。

强制主节点读取锁

1
2
3
4

config.useMasterSlaveServers()
      .setMasterAddress("redis://127.0.0.1:6379")
      .addSlaveAddress("redis://127.0.0.1:6380", "redis://127.0.0.1:6381")
      .setReadMode(ReadMode.MASTER);

其他方式实现分布式锁

除了数据库方式还有其他方式？

基于Zookeeper：

1. 在zookeeper中创建一个锁节点

2. 检查在锁节点的兄弟节点中是否自己创建的节点是最小的。如果是，说明获取到了锁；否则，监听前一个节点的删除事件。

3. 删除自己创建的锁节点，释放锁。

基于etcd:

1. 在 etcd 中创建一个带有租约的键，作为锁的标识。
2. 通过原子操作（如 PUT 请求）确保只有一个客户端能够创建该键。
3. 保持租约的有效性，避免锁过期。
4. 删除创建的键，释放锁。

当然这两种方式比较少用。

布隆过滤器？实现？设计的hash值和函数有什么要求？

布隆过滤器（Bloom Filter）是一种高效的概率数据结构，用于判断一个元素是否存在于一个集合中。它有很高的空间效率和查询效率，但有一定的误判率，即可能会误认为某个不在集合中的元素存在于集合中。布隆过滤器不存储实际的元素，只存储元素的哈希值。

布隆过滤器的基本原理

1. 初始化：创建一个位数组，初始时所有位都设为0。
2. 添加元素：使用k个不同的哈希函数将元素映射到位数组的k个位置上，并将这些位置的值设为1。
3. 查询元素：使用同样的k个哈希函数将查询元素映射到位数组的k个位置上。如果所有这些位置上的值都是1，则认为该元素可能在集合中；如果有任意一个位置上的值为0，则可以确定该元素不在集合中。

优点：

• 空间效率高：相比于直接存储元素集合，布隆过滤器使用的空间要少得多。
• 插入和查询速度快：时间复杂度为O(k)，k是哈希函数的数量。

缺点：

• 存在误判率：查询结果为“存在”时，可能是误判，但查询结果为“不存在”时一定是准确的。
• 无法删除元素：标准布隆过滤器不支持删除操作，删除元素可能会影响其他元素的存在判断。

下面实现代码是GPT写的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

import java.util.BitSet;
import java.util.Random;

public class BloomFilter {
    private BitSet bitSet;
    private int size;
    private int[] hashSeeds;
    private Random random;

    public BloomFilter(int bitSetSize, int hashCount) {
        this.size = bitSetSize;
        this.bitSet = new BitSet(size);
        this.hashSeeds = new int[hashCount];
        this.random = new Random();

        // Initialize hash seeds with random values
        for (int i = 0; i < hashCount; i++) {
            hashSeeds[i] = random.nextInt();
        }
    }

    // Simple hash function
    private int hash(String value, int seed) {
        int result = 0;
        for (char c : value.toCharArray()) {
            result = result * seed + c;
        }
        return (size - 1) & result; // Modulo size to ensure it is within the range
    }

    // Add an element to the Bloom filter
    public void add(String value) {
        for (int seed : hashSeeds) {
            int hash = hash(value, seed);
            bitSet.set(hash);
        }
    }

    // Check if an element might be in the Bloom filter
    public boolean mightContain(String value) {
        for (int seed : hashSeeds) {
            int hash = hash(value, seed);
            if (!bitSet.get(hash)) {
                return false;
            }
        }
        return true;
    }

    public static void main(String[] args) {
        BloomFilter bloomFilter = new BloomFilter(1024, 3);
        bloomFilter.add("hello");
        bloomFilter.add("world");

        System.out.println(bloomFilter.mightContain("hello")); // True
        System.out.println(bloomFilter.mightContain("world")); // True
        System.out.println(bloomFilter.mightContain("bloom")); // False
        System.out.println(bloomFilter.mightContain("filter")); // False
    }
}

Netty线程模型

Netty 基于 NIO （NIO 是一种同步非阻塞的 I/O 模型，在 Java 1.4 中引入了 NIO），使用 Netty 可以极大地简化 TCP 和 UDP 套接字服务器等网络编程，并且性能以及安全性等很多方面都非常优秀。

NIO 是一种同步非阻塞的 I/O 模型，于 Java 1.4 中引入，对应 java.nio包，提供了 Channel , Selector，Buffer 等抽象。NIO 中的 N 可以理解为 Non-blocking，不单纯是 New。它支持面向缓冲的，基于通道的 I/O 操作方法。 NIO 提供了与传统 BIO 模型中的 Socket 和 ServerSocket 相对应的 SocketChannel 和 ServerSocketChannel 两种不同的套接字通道实现,两种通道都支持阻塞和非阻塞两种模式。对于高负载、高并发的（网络）应用，应使用 NIO 的非阻塞模式来开发

netty不用 NIO 主要是因为 NIO 的编程模型复杂而且存在一些 BUG，并且对编程功底要求比较高。而且，NIO 在面对断连重连、包丢失、粘包等问题时处理过程非常复杂。Netty 的出现正是为了解决这些问题，更多关于 Netty 的特点可以看下面的内容。

Reactor 是一种经典的线程模型，Reactor 模式基于事件驱动，特别适合处理海量的 I/O 事件。

单线程 Reactor

所有的 IO 操作都由同一个 NIO 线程处理。

单线程 Reactor 的优点是对系统资源消耗特别小，但是，没办法支撑大量请求的应用场景并且处理请求的时间可能非常慢。

多线程 Reactor

一个线程负责接受请求,一组 NIO 线程处理 IO 操作。

大部分场景下多线程 Reactor 模型是没有问题的，但是在一些并发连接数比较多（如百万并发）的场景下，一个线程负责接受客户端请求就存在性能问题了。

为了解决这些问题，演进出了主从多线程 Reactor 模型。

主从多线程 Reactor

一组 NIO 线程负责接受请求，一组 NIO 线程处理 IO 操作。

在 Netty 主要靠 NioEventLoopGroup 线程池来实现具体的线程模型的 。

我们实现服务端的时候，一般会初始化两个线程组：

1. bossGroup :接收连接。
2. workerGroup ：负责具体的处理，交由对应的 Handler 处理。

从一个 主线程 NIO 线程池中选择一个线程作为 Acceptor 线程，绑定监听端口，接收客户端连接的连接，其他线程负责后续的接入认证等工作。连接建立完成后，Sub NIO 线程池负责具体处理 I/O 读写。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// 1.bossGroup 用于接收连接，workerGroup 用于具体的处理
EventLoopGroup bossGroup = new NioEventLoopGroup(1);
EventLoopGroup workerGroup = new NioEventLoopGroup();
try {
    //2.创建服务端启动引导/辅助类：ServerBootstrap
    ServerBootstrap b = new ServerBootstrap();
    //3.给引导类配置两大线程组,确定了线程模型
    b.group(bossGroup, workerGroup)
            // (非必备)打印日志
            .handler(new LoggingHandler(LogLevel.INFO))
            // 4.指定 IO 模型
            .channel(NioServerSocketChannel.class)
            .childHandler(new ChannelInitializer<SocketChannel>() {
                @Override
                public void initChannel(SocketChannel ch) {
                    ChannelPipeline p = ch.pipeline();
                    //5.可以自定义客户端消息的业务处理逻辑
                    p.addLast(new HelloServerHandler());
                }
            });
    // 6.绑定端口,调用 sync 方法阻塞知道绑定完成
    ChannelFuture f = b.bind(port).sync();
    // 7.阻塞等待直到服务器Channel关闭(closeFuture()方法获取Channel 的CloseFuture对象,然后调用sync()方法)
    f.channel().closeFuture().sync();
} finally {
    //8.优雅关闭相关线程组资源
    bossGroup.shutdownGracefully();
    workerGroup.shutdownGracefully();
}

具体流程如下：

1、首先你创建了两个 NioEventLoopGroup 对象实例：bossGroup 和 workerGroup。

• bossGroup : 用于处理客户端的 TCP 连接请求。
• workerGroup ： 负责每一条连接的具体读写数据的处理逻辑，真正负责 I/O 读写操作，交由对应的 Handler 处理。

这里要注意使用 NioEventLoopGroup 类的无参构造函数设置线程数量的默认值就是 CPU 核心数 *2 。

2、接下来 我们创建了一个服务端启动引导/辅助类： ServerBootstrap，这个类将引导我们进行服务端的启动工作。

3、通过 group() 方法给引导类 ServerBootstrap 配置两大线程组，确定了线程模型。

4、通过channel()方法给引导类 ServerBootstrap指定了 IO 模型为NIO

• NioServerSocketChannel ：指定服务端的 IO 模型为 NIO，与 BIO 编程模型中的ServerSocket对应
• NioSocketChannel : 指定客户端的 IO 模型为 NIO， 与 BIO 编程模型中的Socket对应

5、通过 childHandler()方法给引导类创建一个ChannelInitializer ，然后指定了服务端消息的业务处理逻辑 HelloServerHandler 对象。

6、调用 ServerBootstrap 类的 bind()方法绑定端口。

TCP 粘包/拆包

1.使用 Netty 自带的解码器

• LineBasedFrameDecoder : 发送端发送数据包的时候，每个数据包之间以换行符作为分隔，LineBasedFrameDecoder 的工作原理是它依次遍历 ByteBuf 中的可读字节，判断是否有换行符，然后进行相应的截取。
• DelimiterBasedFrameDecoder : 可以自定义分隔符解码器，实际上是一种特殊的 DelimiterBasedFrameDecoder 解码器。
• FixedLengthFrameDecoder: 固定长度解码器，它能够按照指定的长度对消息进行相应的拆包。如果不够指定的长度，则空格补全
• LengthFieldBasedFrameDecoder：长度域解码器，它能够根据发送的数据中消息长度相关参数（比如长度域偏移量 lengthFieldOffset）来进行拆包。

Netty其他知识后面再梳理下。

Java锁的实现方式

一个是synchronized另一个是ReentrantLock(AQS).

还有个乐观锁(AtomicInteger).

CAS 是一种原子操作，用于确保在多线程环境中，某个值在更新时不会被其他线程修改。Java的 java.util.concurrent.atomic 包提供了一些基于 CAS 的类，这些类实现了乐观锁机制。

例如AtomicInteger, AtomicReference, AtomicStampedReference

• AtomicInteger就不说了。

• AtomicReference 是用于原子操作引用类型的类。它允许原子地更新对象引用，适用于需要保证对象的线程安全的场景。例如AtomicReference<String> reference = new AtomicReference<>("Initial");

• AtomicStampedReference 提供了对引用类型的原子操作，并结合了一个整数戳（通常是版本号），用于解决ABA问题。这个我还没用过。

1
2
3
4
5

AtomicStampedReference<String> stampedReference =
            new AtomicStampedReference<>("Initial", 0);
int[] stamp = new int[1];
        String oldValue = stampedReference.get(stamp);
        stampedReference.set(newValue, stamp[0] + 1);

限流了解吗

令牌桶算法（Token Bucket Algorithm）

令牌桶算法使用一个“桶”来控制数据的流入速率。

桶里有令牌，令牌以固定速率生成。

每次请求需要获取一个令牌，令牌桶中的令牌数量不足时，请求会被拒绝或等待。

令牌桶算法允许突发流量，但总流量受限于桶的大小和令牌生成速率。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

import java.util.concurrent.Semaphore;

public class TokenBucket {
    private final Semaphore tokens;
    private final long refillInterval;
    private final int maxTokens;
    private long lastRefillTime;

    public TokenBucket(int maxTokens, long refillInterval) {
        this.maxTokens = maxTokens;
        this.refillInterval = refillInterval;
        this.tokens = new Semaphore(maxTokens, true);
        this.lastRefillTime = System.currentTimeMillis();
    }

    public synchronized boolean acquire() {
        refill();
        return tokens.tryAcquire();
    }

    private void refill() {
        long now = System.currentTimeMillis();
        long elapsed = now - lastRefillTime;
        if (elapsed >= refillInterval) {
            int newTokens = (int) (elapsed / refillInterval);
            if (newTokens > 0) {
                int availableTokens = Math.min(newTokens, maxTokens - tokens.availablePermits());
                tokens.release(availableTokens);
                lastRefillTime = now;
            }
        }
    }
}

漏桶算法（Leaky Bucket Algorithm）

漏桶算法通过一个“桶”来控制请求流量。

请求以任意速度到达桶中，但桶中的请求以固定速率“漏出”。

当桶满时，多余的请求会被丢弃。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import java.util.concurrent.BlockingQueue;
import java.util.concurrent.LinkedBlockingQueue;

public class LeakyBucket {
    private final BlockingQueue<Object> bucket;
    private final long leakRate;

    public LeakyBucket(int capacity, long leakRate) {
        this.bucket = new LinkedBlockingQueue<>(capacity);
        this.leakRate = leakRate;
        startLeak();
    }

    public boolean add(Object item) {
        return bucket.offer(item);
    }

    private void startLeak() {
        new Thread(() -> {
            while (true) {
                try {
                    Thread.sleep(leakRate);
                    bucket.poll();
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                    break;
                }
            }
        }).start();
    }
}

滑动窗口算法（Sliding Window Algorithm）

滑动窗口算法维护一个时间窗口，在该窗口内控制请求数量。

当请求超出窗口内的最大允许数时，新的请求会被拒绝。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import java.util.LinkedList;
import java.util.Queue;

public class SlidingWindow {
    private final int maxRequests;
    private final long windowSize;
    private final Queue<Long> requests = new LinkedList<>();

    public SlidingWindow(int maxRequests, long windowSize) {
        this.maxRequests = maxRequests;
        this.windowSize = windowSize;
    }

    public synchronized boolean allowRequest() {
        long now = System.currentTimeMillis();
        while (!requests.isEmpty() && now - requests.peek() > windowSize) {
            requests.poll();
        }
        if (requests.size() < maxRequests) {
            requests.add(now);
            return true;
        }
        return false;
    }
}

固定窗口计数器（Fixed Window Counter）

固定窗口计数器维护一个固定时间窗口内的请求计数。

每个窗口开始时计数器被重置，新的请求会增加计数器。

当计数器超出最大允许请求数时，新的请求会被拒绝。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

import java.util.concurrent.atomic.AtomicInteger;

public class FixedWindowCounter {
    private final int maxRequests;
    private final long windowSize;
    private long windowStart;
    private final AtomicInteger requestCount = new AtomicInteger();

    public FixedWindowCounter(int maxRequests, long windowSize) {
        this.maxRequests = maxRequests;
        this.windowSize = windowSize;
        this.windowStart = System.currentTimeMillis();
    }

    public synchronized boolean allowRequest() {
        long now = System.currentTimeMillis();
        if (now - windowStart > windowSize) {
            windowStart = now;
            requestCount.set(0);
        }
        if (requestCount.incrementAndGet() <= maxRequests) {
            return true;
        }
        return false;
    }
}

伪代码实现令牌桶(ratelimiter)？

刚开始我回答用另一个线程或者定时任务去做。

其实实现就是基于上次获取的时间戳来做。

上面已经写了一下。

说实话，挺有意思，没想到用这种方式来考察代码。

后话

今天是8月5号，昨天4号的时候刚好是我离职两月。说焦虑吧，其实早上起床还有晚上睡觉前挺焦虑的，随着面试逐渐增多，我开始怀疑自己，但好像认真做事的时候，比如写东西的时候或者学习的时候感觉也还好，我可能只是觉得空窗太久之后不太好找工作，又或者觉得努力了一段时间没有任何收获，急需一颗糖补充下信心？

稍微统计了一下我从6月下旬开始面试的次数，一共12家公司，16场面试，说实话，我没想到这么难，如果说刚开始是自身原因，那么后续其实都是客观因素了，有面试刷KPI的，有业务不匹配的，有薪酬不合适的。如果后面实在不行，我只能继续试试测试开发岗了，但说实话我真不想做测试开发了。再不行考虑下回家睡大觉。

今天小谢和我说毕业之后第一份工作很重要，因为除非你运气爆棚或者受到赏识，否则你后续都是以这份工作为基础，我觉得说的很对，我好像被锁死上限了。

他也一直和我交流人生，心理上的，比如人生漫漫，不以物喜，不以己悲啊之类的，我觉得说的都挺有道理的。我是一个接受能力比较开放的人，一些观点我其实都是持保留意见，我不反对也不认可，我认为一个观点只有当亲身经历过，才会明白其中的云云。我想这就是人生的意义所在吧，亲身经历与感受各种心情或事物？应该是吧。

有时候我觉得他对人生看的比我透彻，我也羡慕他的豁达。他总是和我说总有办法的，我想也是，只要活着，未来谁又说的准呢？

今天经历了一场长时间面试，接近快两小时，晚上又经历了一场，把我干蒙了，尤其是晚上那场，一共问了三个问题，我都没答上来。寄。。。

复盘

JAVA代码加载执行过程

涉及到类加载过程，根本记不住，就算文档在旁边我也答不上来。

Java代码的加载和执行过程涉及多个步骤，包括编译、类加载、链接、初始化和运行。

1. 编译阶段

Java源代码文件（.java）通过Java编译器（javac）编译成字节码文件（.class）。字节码是一种中间表示形式，它可以在Java虚拟机（JVM）上运行。

2. 类加载阶段

类加载阶段是将类的字节码加载到JVM内存中的过程。类加载器（ClassLoader）负责加载类。

• 启动类加载器（Bootstrap ClassLoader）：加载核心Java类库，如java.lang、java.util等，通常从JVM的运行时环境（rt.jar）中加载。
• 扩展类加载器（Extension ClassLoader）：加载扩展类库，通常从lib/ext目录中加载。
• 应用类加载器（Application ClassLoader）：加载应用程序的类，通常从类路径（classpath）中加载。

3. 链接阶段

链接阶段将类的字节码合并到JVM中，并为其分配内存。链接阶段包括三个子阶段：

• 验证（Verification）：确保字节码符合JVM的规范，并且没有安全问题。
• 准备（Preparation）：为类的静态变量分配内存，并初始化为默认值。
• 解析（Resolution）：将常量池中的符号引用替换为直接引用。

4. 初始化阶段

初始化阶段是执行类构造器方法 <clinit> 的过程。类构造器方法 <clinit> 是由编译器自动生成的，它包含类静态变量的赋值和静态代码块的执行。

5. 执行阶段

在执行阶段，JVM开始执行应用程序的main方法。整个应用程序的执行过程由JVM的执行引擎来处理。执行引擎包括以下几个部分：

• 解释器（Interpreter）：逐行解释执行字节码。
• 即时编译器（Just-In-Time Compiler, JIT）：将热点代码（执行频繁的代码）编译成本地机器码，以提高执行效率。
• 垃圾收集器（Garbage Collector, GC）：管理内存，回收不再使用的对象。

1
2
3
4
5

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

假设我们有上述简单的Java代码，以下是详细的加载和执行过程

编译：

• 使用 javac Main.java 编译器将 Main.java 编译为 Main.class 字节码文件。

类加载：

• JVM启动时，启动类加载器首先加载核心类库。
• 应用类加载器加载 Main 类的字节码，将其放入方法区，并创建一个 Class 对象表示 Main 类。

链接：

• 验证：JVM验证 Main.class 字节码是否合法。
• 准备：为 Main 类的静态变量分配内存并初始化为默认值（此例中没有静态变量）。
• 解析：将常量池中的符号引用解析为直接引用。

初始化：

• 执行 Main 类的静态初始化代码（如有），包括静态变量的初始化和静态代码块（此例中没有静态初始化代码）。

执行：

• JVM调用 Main 类的 main 方法。
• 解释器解释执行 main 方法的字节码，将 Hello, World! 打印到控制台。
• JIT编译器在执行频繁的代码时将其编译为本地机器码，以提高执行效率。

JAVA中能否加载相同类名?自定义java.lang.String能否加载？

在Java中，可以加载具有相同类名的类，但需要通过不同的类加载器来实现。每个类加载器都有其独立的命名空间，因此可以加载同名类而不冲突。这种机制在实现Java应用程序中的模块化、插件化和动态加载时非常有用。

类加载器：负责加载类文件到JVM内存中。Java中的类加载器包括引导类加载器（Bootstrap ClassLoader）、扩展类加载器（Extension ClassLoader）和应用类加载器（Application ClassLoader）。还可以自定义类加载器。

命名空间：每个类加载器都有自己的命名空间，包含其加载的所有类。不同类加载器的命名空间是独立的，这意味着两个不同类加载器可以加载同名的类而不冲突。

简单来说就是使用不同的类加载器来加载类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public class ClassLoaderTest {
    public static void main(String[] args) {
        try {
            // Load MyClass from dir1
            CustomClassLoader classLoader1 = new CustomClassLoader("bin/dir1/");
            Class<?> class1 = classLoader1.loadClass("com.example.MyClass");
            Object obj1 = class1.newInstance();
            class1.getMethod("print").invoke(obj1);

            // Load MyClass from dir2
            CustomClassLoader classLoader2 = new CustomClassLoader("bin/dir2/");
            Class<?> class2 = classLoader2.loadClass("com.example.MyClass");
            Object obj2 = class2.newInstance();
            class2.getMethod("print").invoke(obj2);

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

在Java中，自定义 java.lang.String 类并尝试加载它是非常困难的，因为 java.lang.String 是由引导类加载器（Bootstrap ClassLoader）加载的核心类。引导类加载器是JVM的一部分，用于加载核心Java类库，它有最高的优先级并且不允许由其他类加载器覆盖这些核心类。

引导类加载器的优先级：引导类加载器首先加载核心类库，包括 java.lang.String。由于它是最先被加载的类加载器，并且在JVM启动时就已经加载了核心类，其他类加载器不能覆盖或重新定义这些类。

双亲委派模型：Java的类加载器遵循双亲委派模型，即当一个类加载器加载类时，它首先委派给其父类加载器。如果父类加载器已经加载了这个类，子类加载器就不会再加载它。由于 java.lang.String 是由引导类加载器加载的，所有其他类加载器在加载 java.lang.String 时都会被委派给引导类加载器，从而无法加载自定义的 java.lang.String。

虽然理论上可以通过一些非常规手段尝试加载自定义的 java.lang.String 类，但在标准JVM实现中，这样的操作通常会失败或导致异常。以下是一些可能的方式和其局限性：

1. 通过自定义类加载器：即使你编写了一个自定义类加载器并尝试加载自定义的 java.lang.String，由于双亲委派模型，最终还是会委派给引导类加载器。
2. 修改引导类路径：可以尝试将自定义的 java.lang.String 放在引导类路径上，但这需要修改JVM的启动参数，且一般来说这不被推荐，因为它会破坏JVM的稳定性和安全性。

mysql也能存储json，为什么mongo比mysql快

1. 数据模型和存储机制

MongoDB：

• MongoDB 是一个文档数据库，设计上天然支持 JSON（实际上是 BSON，Binary JSON）。
• 数据以文档的形式存储，每个文档是一个键-值对的集合，可以嵌套和具有多样的结构。
• MongoDB 的文档模型更接近 JSON 的原始结构，因此存储和读取 JSON 数据时更加高效。

MySQL：

• MySQL 是一个关系型数据库，虽然它支持 JSON 数据类型，但其设计主要针对结构化数据。
• MySQL 在存储 JSON 数据时，通常将其作为字符串处理，需要额外的解析和转换。
• 对 JSON 数据的查询和操作需要额外的步骤，如解析 JSON 字符串，这会影响性能。

2. 索引和查询优化

MongoDB：

• MongoDB 支持在文档中的嵌套字段上创建索引，这使得对嵌套 JSON 结构的查询更高效。
• MongoDB 的查询语言和引擎专为文档结构设计，能够直接对 BSON 结构进行操作，无需额外的解析步骤。
• 由于设计上的优势，MongoDB 在进行复杂的嵌套查询时性能更好。

MySQL：

• MySQL 也支持对 JSON 字段创建索引，但其索引机制和查询优化主要为关系型数据设计。
• 查询 JSON 数据时，MySQL 需要先解析 JSON 字符串，然后再执行查询，增加了额外的开销。
• 对嵌套 JSON 结构的查询在 MySQL 中较为复杂，可能需要使用函数和额外的步骤来解析和提取数据。

3. 数据更新和写入

MongoDB：

• MongoDB 的写入操作设计上更加灵活，支持文档的部分更新。
• 对于 JSON 数据的更新，MongoDB 能够直接修改文档中的嵌套字段，而无需整体替换。
• 这种灵活性使得对 JSON 数据的写入和更新操作更高效。

MySQL：

• MySQL 对 JSON 数据的更新通常需要解析和重新构建整个 JSON 字符串，尤其是对于嵌套结构。
• 这种操作增加了写入和更新的开销，导致性能下降。

4. 并发处理和扩展性

MongoDB：

• MongoDB 的架构设计为分布式存储和高并发处理进行了优化。
• 通过分片和复制集机制，MongoDB 能够轻松扩展以应对大规模的数据量和高并发请求。

MySQL：

• MySQL 也支持分布式和集群架构，但其扩展性主要针对关系型数据。
• 对于大规模 JSON 数据的处理，MySQL 的性能和扩展性可能不如 MongoDB。

总结

这次真的一问三不知，另一场两小时面试基础问题比较多，周末整理下看看再发一篇。

反射是什么 怎么用

刚开始我愣了一下，在大学的时候我其实也写过关于反射的文章，结果忘得差不多了。

其实就是借助class对象获取类信息的方式称作反射。

1
2
3
4
5
6

//1
Class c1 = Cat.class; //任何类都有隐含的静态成员class用于获取Class对象
//2
Class c2 = cat.getClass();//实例有一个getClass方法获取Class对象
//3
Class c3 = Class.forName("Cat");

如果使用getMethods则可以获取所有方法。但是getMethod和getMethods获取的是public方法，如果需要获得私有方法，则使用getDeclaredMethod方法。

获取成员则是使用getField/getDeclaredField.

获取构造器是getConstructor/getDeclaredConstructor

Java中的常用集合 底层结构

Java 集合，也叫作容器，主要是由两大接口派生而来：一个是 Collection接口，主要用于存放单一元素；另一个是 Map 接口，主要用于存放键值对。对于Collection 接口，下面又有三个主要的子接口：List、Set 、 Queue。

ArrayList底层是Object[] 数组。动态进行扩容。

TreeSet底层是红黑树。

用redis实现延迟队列

使用sortedSet来实现

添加任务：使用ZADD命令将任务添加到有序集合中，分数为任务的执行时间。

消费任务：使用ZRANGEBYSCORE命令获取到期的任务，并使用ZREM命令从有序集合中删除这些任务。

CAP理论

一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）。

根据CAP定理，在一个分布式系统中，最多只能同时满足这三个属性中的两个。

一致性（Consistency）：

• 在一个分布式系统中，一致性指的是所有节点在同一时间看到的数据是相同的。换句话说，每次读操作都能够返回最近一次写操作的结果。

可用性（Availability）：

• 可用性指的是系统在任何时间都是可用的，并且每个请求都能够得到非错误的响应（不保证返回最新的数据）。即使某些节点发生故障，系统仍然能够响应请求。

分区容忍性（Partition Tolerance）：

• 分区容忍性指的是系统能够继续操作，即使网络分区（Partition）发生了。网络分区是指网络中的一些节点无法与其他节点通信，但系统仍然能够正常工作。

CA（Consistency and Availability）：

• 系统在正常操作时保证一致性和可用性，但在网络分区时无法容忍。
• 例子：传统的关系型数据库（如单一的SQL数据库）。

CP（Consistency and Partition Tolerance）：

• 系统在网络分区时保证一致性，但可能会牺牲部分可用性。
• 例子：一些分布式数据库（如HBase、MongoDB在强一致性配置下）。

AP（Availability and Partition Tolerance）：

• 系统在网络分区时保证可用性，但可能无法保证强一致性。
• 例子：一些NoSQL数据库（如Cassandra、DynamoDB）。

分布式锁实现

有redis分布式锁和mysql的悲观锁。

使用SET命令以NX和EX选项来设置锁键。

使用DEL命令来释放锁。

使用一个唯一的值（通常是UUID）来标识锁持有者，以防止误删他人的锁。

NX 选项

• 含义：NX选项表示”只在键不存在时设置”（Not Exists）。
• 功能：当NX选项指定时，SET命令只会在键不存在的情况下设置键值。如果键已经存在，SET命令不会执行任何操作。
• 用途：常用于分布式锁的实现，确保只有一个客户端能够成功设置锁，防止多个客户端同时获得锁。

EX 选项

• 含义：EX选项表示”设置键的过期时间”（Expire）。
• 功能：当EX选项指定时，SET命令会在设置键值的同时，为键设置一个过期时间（以秒为单位）。键在过期时间到达后将自动删除。
• 用途：用于设置键的自动过期，防止因持有锁或设置值过长时间而导致系统资源泄漏。对于分布式锁，设置锁的过期时间非常重要，以确保锁不会无限期地占用，导致系统无法恢复。

死锁与避免

在计算机系统中，死锁的发生通常需要满足以下四个条件，这四个条件被称为死锁的必要条件：

1. 互斥（Mutual Exclusion）：资源不能被多个进程（或线程）同时占用，即资源在某一时刻只能被一个进程（或线程）使用。
2. 占有并等待（Hold and Wait）：进程（或线程）已经持有一个或多个资源，并且正在等待其他资源，而这些资源被其他进程（或线程）持有。
3. 非抢占（No Preemption）：已经分配给进程（或线程）的资源在被释放之前不能被抢占，资源只能在进程（或线程）自愿释放后才能被其他进程（或线程）获取。
4. 循环等待（Circular Wait）：存在一个进程（或线程）集合，其中每个进程（或线程）都在等待下一个进程（或线程）释放资源，形成一个循环链。

预防就是破坏四个条件。

避免可以使用银行家算法：在资源请求时，通过检查是否能保证系统处于安全状态来决定是否分配资源。只有在分配资源后系统仍然处于安全状态时，才允许该资源分配。

检测使用资源分配图（Resource Allocation Graph）或其他检测机制来检测系统中是否存在死锁。

恢复：

• 终止进程：选择一个或多个进程终止，以释放资源。
• 资源抢占：从某些进程中抢占资源，分配给其他进程，以打破死锁循环。

git切换分支？ 复制某个commit？

平常git用的不多。只回答上第一个。

使用git checkout来切换分支。

如果你想从某个特定的提交创建一个新的分支：

1
2
3

git checkout -b <new-branch-name> <commit-hash>
或者
git switch -c <new-branch-name> <commit-hash>

如果你想将某个提交的更改应用到当前分支，可以使用git cherry-pick：

1

git cherry-pick <commit-hash>

maven怎么解决依赖冲突

使用mvn dependency:tree查看冲突依赖，然后在pom文件中使用<exclusions>排除依赖。

也可以在pom.xml文件中，通过<dependencyManagement>标签来强制使用特定版本的依赖。

使用mvn dependency:analyze这个命令可以识别未使用和未声明的依赖。

对称加密和非对称加密算法？有什么优缺点

对称加密是指加密和解密使用相同的密钥。常见的对称加密算法有AES（Advanced Encryption Standard）、DES（Data Encryption Standard）和3DES（Triple DES）。

优点

1. 速度快：对称加密算法通常比非对称加密算法快，因为它们的计算复杂度较低，适合处理大量数据。
2. 效率高：对称加密适用于需要高性能加密的场景，如大数据传输、磁盘加密等。
3. 资源消耗少：对称加密的计算资源消耗通常较低，因此适合在资源有限的环境中使用。

缺点

1. 密钥管理困难：对称加密需要确保密钥的安全传输和存储，密钥的分发和管理是一个挑战。

2. 不适合分布式系统：在大规模分布式系统中，密钥的管理和分发变得更加复杂，需要额外的机制来确保安全性。

3. 密钥泄露风险：一旦密钥泄露，所有用该密钥加密的数据都可能被解密，因此密钥的保护至关重要。

非对称加密（或称公钥加密）使用一对密钥：公钥和私钥。公钥用于加密，私钥用于解密。常见的非对称加密算法有RSA（Rivest–Shamir–Adleman）、ECC（Elliptic Curve Cryptography）和DSA（Digital Signature Algorithm）。

优点

1. 密钥管理简化：非对称加密解决了密钥分发的问题。公钥可以公开，而私钥保持秘密。
2. 数字签名：非对称加密支持数字签名，可以验证数据的真实性和完整性。
3. 加密密钥交换：常用于安全的密钥交换，例如在HTTPS中使用非对称加密来安全地交换对称加密密钥。

缺点

1. 速度较慢：非对称加密通常比对称加密慢，因为它需要更复杂的数学运算，适合加密小量数据。
2. 资源消耗大：计算和存储资源消耗较高，因此不适合大规模数据的加密。
3. 计算复杂性：非对称加密的算法复杂度较高，实施和优化可能较为复杂。

spring框架有什么设计模式？aop用的是什么？

单例模式：通过配置Bean的作用域为singleton（默认值），Spring在启动时创建唯一的Bean实例。

代理模式：Spring使用代理模式来实现AOP（面向切面编程）。通过动态代理或CGLIB字节码生成，Spring可以在运行时创建代理对象，并在方法调用前后插入额外的逻辑（如事务管理、日志记录等）。

模板方法模式： Spring的JdbcTemplate、JmsTemplate和HibernateTemplate等类使用模板方法模式来简化常见的操作。模板方法模式定义了操作的算法框架，将某些步骤的实现延迟到子类。

工厂模式：Spring使用工厂模式来创建Bean实例。Bean的创建由Spring容器负责，开发者只需要定义Bean的配置，Spring容器在运行时根据配置创建和管理Bean。

策略模式： Spring的许多组件使用策略模式来定义算法的变体，而不需要修改客户端代码。例如，Spring的TransactionManager接口允许不同的事务策略实现，如DataSourceTransactionManager、JpaTransactionManager等。

观察者模式：Spring的事件发布和监听机制使用了观察者模式。Spring允许应用程序通过事件发布和监听来实现松耦合的组件交互。ApplicationEvent和ApplicationListener接口，ApplicationContext作为事件发布者，监听器作为观察者。

装饰器模式：Spring AOP的一个实现，特别是ProxyFactoryBean，使用了装饰器模式来增强对象的功能，而不需要改变其结构。通过在代理对象上添加额外的功能来装饰原始对象。Spring AOP中的切面（Aspect）和建议（Advice）可以看作是对目标对象的装饰。

算法题

输入一个字符串n1, 由数字与”,”分隔，输出这个序列中第二大的数字，以字符串返回。

还算比较简单，就是先切分字符串，然后用Integer.valueOf变成数字，然后用两个变量记录最大和第二大的数字。

面试时写的时候忘记考虑没有第二大的数字了。现在让GPT又写了一下才恍然大悟。

1
2
3
4
5
6
7
8
9
10
11
12
13

// 找到最大的和第二大的数字
Integer largest = null;
Integer secondLargest = null;

for (Integer number : uniqueNumbers) {
    if (largest == null || number > largest) {
        secondLargest = largest;
        largest = number;
    } else if (secondLargest == null || (number > secondLargest && number < largest)) {
        secondLargest = number;
    }
}
return (secondLargest != null) ? String.valueOf(secondLargest) : null;

总结

没想到都是八股文，措手不及，其中最后一个aop用的是什么设计模式我竟然转不过脑子来。

也有一些没答出来，比如chery-pick，反射也答得不好，sortedSet如何删除也没答出来。

包括代码编写只面试了半个小时，不知道咋说，准备下一场其他面试吧。。

今天面试不咋顺利。

面试完后得知一个同事去了百度，我既替他高兴，但我自己也很难受。我面试了好多家都不咋顺利，他一说他base只有18，我就知道原来我要价太高了。

还是挺难受的，我觉得我并不比他差。但也只能接受，有时候面试就是看运气还有眼缘的。

复盘

算法题

算法题是最后问的，我挪到前面来。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

static class Flight {
    /**
     * 出发城市
     */
    public String cityFrom;
    /**
     * 到达城市
     */
    public String cityTo;
    /**
     * 航班价格
     */
    public int price;
    /*
     * 航班号
     */
    public String flightNo;

    public Flight(String cityFrom, String cityTo, int price, String flightNo) {
        this.cityFrom = cityFrom;
        this.cityTo = cityTo;
        this.price = price;
        this.flightNo = flightNo;
    }

    @Override
    public String toString() {
        return "Flight{" +
                "cityFrom='" + cityFrom + '\'' +
                ", cityTo='" + cityTo + '\'' +
                ", price=" + price +
                ", flightNo='" + flightNo + '\'' +
                '}';
    }
}


/**
 * 找出 fromCity 至 toCity 最便宜的航班组合并返回
 * @param flights
 * @param fromCity
 * @param toCity
 * @return
 */
public static List<Flight> searchLowestPriceFlightCombination(
        Set<Flight> flights,
        String fromCity,
        String toCity) {

    // TODO


}

面试官就发了一道这种题目。

我就写成了直达做法，但实际上面试官是要考察包括中转的情况。有点尴尬。。我就说怎么这么简单。其实应该用BFS（广度优先）去做的。

也是请教了GPT.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

public static List<Flight> searchLowestPriceFlightCombination(
            Set<Flight> flights,
            String fromCity,
            String toCity) {

        Map<String, List<Flight>> graph = new HashMap<>();
        for (Flight flight : flights) {
            graph.computeIfAbsent(flight.cityFrom, k -> new ArrayList<>()).add(flight);
        }

        // Queue to hold the paths and their corresponding total price
        Queue<List<Flight>> queue = new LinkedList<>();
        // Map to hold the minimum cost to reach each city
        Map<String, Integer> minCost = new HashMap<>();
        minCost.put(fromCity, 0);

        // Start with the fromCity with an empty path
        queue.add(new ArrayList<>());

        List<Flight> result = new ArrayList<>();
        int minTotalCost = Integer.MAX_VALUE;

        while (!queue.isEmpty()) {
            List<Flight> currentPath = queue.poll();
            String lastCity = currentPath.isEmpty() ? fromCity : currentPath.get(currentPath.size() - 1).cityTo;

            if (lastCity.equals(toCity)) {
                int currentCost = currentPath.stream().mapToInt(f -> f.price).sum();
                if (currentCost < minTotalCost) {
                    minTotalCost = currentCost;
                    result = new ArrayList<>(currentPath);
                }
                continue;
            }

            for (Flight nextFlight : graph.getOrDefault(lastCity, new ArrayList<>())) {
                int newCost = currentPath.stream().mapToInt(f -> f.price).sum() + nextFlight.price;

                if (newCost < minCost.getOrDefault(nextFlight.cityTo, Integer.MAX_VALUE)) {
                    minCost.put(nextFlight.cityTo, newCost);
                    List<Flight> newPath = new ArrayList<>(currentPath);
                    newPath.add(nextFlight);
                    queue.add(newPath);
                }
            }
        }

        return result;
    }