尽管离职遇到裁员潮、遇到北京疫情,但是我用半个月的时间约面-上岸,现在安心休息几天随后入职!
内心焦虑在58一年半,没有涨过工资,这个也是我离职的导火索.具体详情就不描述了,当离职遇到裁员潮、遇到五一节、遇到北京疫情,心情还是有点糟糕,boss直聘上跟人家打招呼基本已读不回,花了68块钱办了一个月的会员,它的作用就是每天帮我自动刷新简历…很多互联网公司不招人,我个人感觉工作没有着落,内心逐渐失落、焦虑、沮丧.
世间最难的事情就是认识自己!正确定位自己、认识自己,在夜深人静的时候,试着了解自己的性格,发现自己的偏好,找准自己的定位,明确自己的方向,知晓自己有什么、缺什么,自己能干什么、还需要什么,并渐渐地将外在的情势与自身的优势进行整合,正确的方向就会由此浮出水面.这样也会避免不必要的焦虑和痛苦并且在合理的范围内寻求发展和突破.
做好规划离职遇到五一放假,认真分析形式,不要抱有任何幻想在五一之前入职,所以我五一前放弃找工作,用一周的时间调整心态,正视现在的处境,剩下时间开始复习基础知识、查找面试资料,为什么我找的资料可以应对85%的面试,这就不得不提一下,平时我下班后喜欢带着笔记本回来,每天都会找一些博文、自己做一些事情,日积月累资料就积累起来了,当用到时候随手定位资料位置或者是自己的网页存储位置,背书就好.
不管什么时候都要时刻保持危机感时刻做着准备,正所谓不做准备的人就是准备失败的人!未雨绸缪、居安思危是我们必须懂得的道理!
调整心态把「了凡」变成「重燃」.我希望重燃激情、重燃信念、重燃梦想、拒绝躺平、拒绝平庸.二十岁的时候,做什么事情都充满了激情,十年之后的现在,我通过这段经历,发现我的激情快被生活和工作消磨殆尽…
曾经有数不清的黎明我对着朝霞低吟浅唱,曾经有无数个黄昏我对着夕阳倾诉我的向往.而如今呢?却因为一点点挫折,内心满是沮丧…我心有不甘,所以我用了一周的时间调整自己的心态.什么都不想什么都不做,看看励志的故事看看励志的视频!其中有一句话对我的触动特别大:“命运给你一个低谷,不是想看你自甘堕落,而是想看你如何逆风翻盘.”,我把这句话送给看到这篇文章的人,祝愿你们越来越好!!!
技术值钱吗在调整心态的一周时间,我终于承认了一件事情,“技术不值钱”,以前我看到过这段话,也很不愿意承认它,曾经还喷过说出这句话的人,但是通过我的个人经历,我发现能力再强,失去了施展能力的平台,技术一文不值,有人可能也会跟我当初似的去质疑这句话,并且把辩证观点摆出来,你拿着那些观点自己去想一下,有几个人能实施呢?
我一个人从服务器、前端、后端都能做,个人认为我学习技术的能力和工作能力都很强,但没有了工作,突然感觉我自己什么都不是.失去平台,通过技术变现还是很难的,因为现在绝大多数人都愿意去白嫖!
学历相较能力更重要这次找工作的经历给我最大的感触就是学历非常重要,很多企业招聘信息上标注着一本、985、211,国企招聘也有很多这个标注,不曾想,我们国家现在都卷到这种地步了,年龄、学历卷的是越来越厉害!
很多人说学历是下限能力是上限,但如果你都没有机会、没有平台,你的能力又怎么施展呢?
很多企业都愿意选一个能力不行,但是有学历的人去培养,别不相信!
我内推前同事,58的同事面他之后反馈给我的消息就是技术水平不行,但是二线厂把他录用了,原因就是他的学校是211,我投简历到那个公司,人家根本都不给我面试的机会…这就是现实!
别把平台当本事现在很多人有学历但是没教养,你在求职平台上跟人家发消息,已读不回,做人的基本素质都没有…这种人跟卖钻石的、卖豪车的一些人一样,时间久了以为都是他家的…是他很牛一样…
说一下这次约面百度的AGC支付的经历,所谓的面试官态度敷衍,面试应付,没有招人的意思,十几分钟草草了事,态度傲慢至极,不知道他哪里来的底气.
我也当过面试官,我也被人面过,但是我知道要给面试者最基本的尊重,现在的初面一般都是以后共事的同事,没有title,又何必把自己过分的想成多牛逼的样子呢?真真应了那句话,阎王好见小鬼难缠!
我想对那些叼毛说一句:”别把运气当才华,别把平台当本事.有智而气和,斯为大智;有才而性缓,方为大才“.祝福那些叼毛的垃圾话就不彪了,毕竟那种人可以主宰一场面试,但不能主宰别人的人生,而我又何必因为一个本来就没有交集的人过分纠结!
别把平台当本事,因为离开平台,剩下的才是我们的底气和本事.
大部分互联网人都知道58是个所谓的养老公司,我进58的时候本来也是抱着躺平的心态进去的,但是一年半都不给涨工资真是让我大跌眼镜,而且各种小事不断,被产品告状说我摸鱼,我就呵呵了,一个需求要求五天做完,我一天或者两天就做完了,剩余时间我刷刷博客刷刷文章不可以吗?事实证明不可以,别人只看到的你晚来早走,根本不会看到你早来晚走…
算命先生的嘴也跟开了光一样,今年1~5月不升职、加薪、跳槽…我本意不想跳槽,但是总会有一只无形的手推着你走这一步!我也只能感叹道:“一切皆是命,半点不由人”.
“要会拉套要会看道”这句话是我妈用半辈子的工作经历总结出来的,我觉得充满了人生哲理!
做正确的事情比正确的做事更重要!学会人情世故学会为人处事,是我们成功不可或缺的能力.很多时候不是因为你能力强就会受到重视,而且我们必须正视这个事实!
比如:我养了两只乌龟,一只是草龟,一只是鳄龟,草龟很温顺很会来事、认识我并且会跟我互动,反观鳄龟,凶猛无比,只要挑逗它,它就张嘴想咬我,我肯定更喜欢草龟啦!我有的时候尚且如此,换位思考一下其他人呢?或者这样想一下,自己更喜欢和自己抬杠的人相处还是更喜欢与自己交好的人相处呢?
人教人教不会,事教人一次成我可能就吃了上述事情的亏,所以我对此有了深刻的认识,接下来如何走下一步,我也有了相应的计划和策略,不管别人怎么说怎么教,如果不能真实体会,可能就是学不会,经历是用钱买不到的,多经历一些未必是坏事.好好品味品味这句话吧:“人教人教不会,事教人一次成”!
心态变化待业时焦虑,调整心态后平稳,当手头有一份offer的时候心里悬着的石头终于落地了并且带了一丝的兴奋,当手里offer多了的时候,又开始纠结了,感觉走到了一个岔路口不知道要选择哪一条路.
不过有了offer之后整体上心情舒缓了很多,回顾这一个月,心情波动起伏很大.但是调整心态、规划未来的能力在这个时候显得颇为重要!不要自暴自弃,要学会战胜自己!越是在自己感觉艰难的时候越要多看积极向上的、对自己有帮助的资料!
共勉无惧人间笑面鬼,雄才终有出头日.欲要登顶成龙凤,岂怕世间磨难多.时来天地皆同力,运到万物皆同行!人生没有过不去的坎儿,如果有可能是因为自己腿短,多从自身找原因,找出路!自助者天助之,别指望别人.
为什么我要说自助者天助之,猎头推的工作基本都是跟他们利益挂钩的,我拿到offer这几家公司,跟猎头没有半毛钱关系,而且如果猎头觉得你没有价值后,即便你找他帮忙,他可能都不会回复你!
《鼠胆威龙》中那个医生的口头禅,我觉得很是耐人寻味,“人要靠自己”,当一个人自己都放弃自己了,那这个人就无药可救了,但不论一个人遇到什么挫折,他都能从容面对,这种人必将有所成就!
加油吧朋友们!祝好!!!
kafka如何实现顺序消费?在kafka提交offset的时候,可能由网络延迟或者某些原因导致,offset没有同步,导致其他consumer消费了已经消费的消息
kafak如何保证消息不丢失?kafak的话需要将顺序消费的消息通过指定分区策略发送到指定的partition中
如果了解rocketMq的话,可以顺带一句,rkmq自带顺序消息功能,分为全局顺序和局部顺序消息,一般情况下都采用局部顺序消息这种机制
消息进入死信队列的条件?生产端: ack = all,reties次数加大;消费端:关闭自动提交offset,消费消息成功后手动提交offset
- 消息到达超时时间
- 队列长度到达限制
- 消息拒绝签收，不把消息放入原队列中
- 浅拷贝：在拷贝一个对象时,对对象的基本数据类型的成员变量进行拷贝,但对引用类型的成员变量只进行引用的传递,并没有创建一个新的对象,当对引用类型的内容修改会影响被拷贝的对象。
- 深拷贝：在拷贝一个对象时,除了对基本数据类型的成员变量进行拷贝,对引用类型的成员变量进行拷贝时,创建一个新的对象来保存引用类型的成员变量。
- sleep 是thread方法,sleep 过程中线程不会释放锁,只会阻塞线程
- wait 是object方法,wait 过程中线程会释放对象锁,只有当其他线程调用 notify 才能唤醒此线程
- yeild 是thread方法,不是释放资源锁,调用yeild的线程进入就绪状态
- join 是等待调用join方法的线程结束之后，程序再继续执行
- syn是关键字 lock是接口
- lock需要手动加锁和释放锁,syn不需要
- lock只能锁代码块,syn可以锁类、方法、代码块
- syn是非公平锁,lock既可以是公平锁也可以是非公平锁,默认是非公平锁
- syn修饰的代码在执行异常时,jdk会自动释放线程占有的锁,当Lock发生异常时,如果程序没有通过unLock()去释放锁,则很可能造成死锁现象
- lock可以让等待锁的线程响应中断处理,如tryLock(long time, TimeUnit unit),而syn不行,使用syn时,等待的线程会一直等待下去,不能够中断
- lock可以绑定条件,实现分组唤醒需要的线程；syn要么随机唤醒一个,要么唤醒全部线程
cms应用于老年代,g1应用于内存大于8G的机器,g1不在物理上区分年轻代和老年代
说一下ThreadLocal?作用:每个线程都会有一份自己的资源变量
为什么要使用线程池?ThreadLocalMap中使用的key为ThreadLocal的弱引用,value为强引用。当ThreadLocal没被外部引用时key会被GC回收,导致key为null,而value永远无法被回收从而内存泄漏。最好每次用完ThreadLocal后手动调用remove（）。
- 降低资源消耗
- 提高响应速度
- 提高线程的可管理性
为什么要设置Survivor区?如果采用两次握手，那么只要服务器发出确认数据包就会建立连接，但由于客户端此时并未响应服务器端的请求，那此时服务器端就会一直在等待客户端，这样服务器端就白白浪费了一定的资源。若采用三次握手，服务器端没有收到来自客户端的再此确认，则就会知道客户端并没有要求建立请求，就不会浪费服务器的资源。
- 如果不设置Survivor区 只有eden区 存活的的对象就会直接被放到送到老年代,老年代被填满就会触发触发Major GC（因为Major GC一般伴随着Minor GC，也可以看做触发了Full GC）
- 设置两个Survivor区最大的好处就是解决了碎片化
解决的核心原理就是：在对象实例化之后，依赖注入之前，Spring提前暴露的Bean实例的引用在第三级缓存中进行存储。
- 一级缓存 singletonObjects (concurrentHashmap)
- 二级缓存 earlySingletonObjects (hashmap)
- 三级缓存 singletonFactory (hashmap)
- 聚簇索引:数据跟索引绑定在一起
- 非聚簇索引:数据跟索引分开存储
- 每一列都是不可分割的,原子性
- 如果表是单主键,那么主键以外的列必须完全依赖于主键;如果表是复合主键,那么主键以外的列必须完全依赖于主键,不能仅依赖主键的一部分.
- 表中的非主键列必须和主键直接相关而不能间接相关
- statement格式的 binlog，完整的标识是最后有 COMMIT 关键字
- row 格式的binlog，完整的标识是最后会有一个 XID event 关键字
- 查询速度慢的原因很多:
- 查询字段没有索引或者没有触发索引查询
- I/O 压力大，读取磁盘速度变慢
- 内存不足
- 网络速度慢
- 查询出的数据量过大，可以采用多次查询或其他的方法降低数据量
- 死锁
- 解决方式:
- 正确创建和使用索引。
- 把数据、日志、索引放到不同的 IO 设备上，减少主数据库的 IO 操作。更换 MySQL 的磁盘为固态硬盘，以提高磁盘的 IO 性能。
- 升级内存，更换更大的内存。
- 提升网速，升级带宽。
- 用 Profiler 来跟踪查询，得到查询所需的时间，找出有问题的 SQL 语句，优化 SQL。
- 查询时值返回需要的字段。
- 设置死锁的超时时间，限制和避免死锁消耗过多服务器的资源。
- 存储引擎:不同的数据文件在磁盘的组织形式
- frm:表结构
- ibd:数据和索引文件
- 不符合最左匹配原则
- 索引列有计算
- 有or
- 模糊查询 like %
- 索引列有函数
- 需要类型转换
- 聚集索引一个表只能有一个，而非聚集索引一个表可以存在多个
- 聚集索引存储记录是物理上连续存在，而非聚集索引是逻辑上的连续，物理存储并不连续
- 聚集索引：物理存储按照索引排序；聚集索引是一种索引组织形式，索引的键值逻辑顺序决定了表数据行的物理存储顺序
- 非聚集索引：物理存储不按照索引排序；非聚集索引则就是普通索引了，仅仅只是对数据列创建相应的索引，不影响整个表的物理存储顺序.
- 索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
- 聚集索引是主健索引或第一个不为空的唯一索引
- 非聚集索引实际上就是普通索引
- 不可以，binlog 没有崩溃恢复的能力
- redo log 是循环写不能保证所有的历史数据,这些历史数据只能在 binlog 中找到
- binlog 是高可用的基础,高可用的实现原理就是 binlog 复制.
什么叫回表查询?最多可以创建 16 个索引列.
mysql的innodb和myisam区别?普通索引查询到主键索引后,回到主键索引树搜索的过程,我们称为回表查询.
- innodb 支持外键,myisam不支持
- innodb 支持事物,myisam不支持
- innodb 支持崩溃后数据恢复
- innodb 支持行级锁,myisam支持表锁
- innodb 不支持全文索引,myisam支持fulltext
死锁概念:是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去
- 查出死锁线程 select trx_MySQL_thread_id from information.schema.innodb.trx; 并且kill掉
- 设置锁的超时时间, innodblock_wait_timeout= 1000
- 开启满查询日志,定位哪条语句有问题
- 通过执行计划分析sql语句,获得其使用索引的情况,之后修改语句或者修改索引,使得语句尽可能命中索引
- 如果语句无法继续优化,考虑数据量太大,进行垂直或者水平分表
- table
- type
- key
- extra
- B 树：不管叶子节点还是非叶子节点，都会保存数据，这样导致在非叶子节点中能保存的指针数量变少（有些资料也称为扇出），指针少的情况下要保存大量数据，只能增加树的高度，导致IO操作变多，查询性能变低；
- Hash：虽然可以快速定位，但是没有顺序，IO 复杂度高；
- 二叉树：树的高度不均匀，不能自平衡，查找效率跟数据有关（树的高度），并且 IO 代价高；
- 红黑树：树的高度随着数据量增加而增加，IO 代价高。
- 读未提交
- 读已提交
- 可重复读
- 串行
- 独立性
- 一致性
- 持久性
- 原子性
- 脏读:读取了其他事务未提交的数据.
- 不可重复读:在事务A多次读取数据过程中,事务B修改了这个数据,导致事务A读取的数据不一致.
- 幻读:A修改所有的数据为1的时候,B新增了一条数据,A修改结束后发现还有一条记录没有改过来.
不可重复读侧重于修改,幻读侧重于新增或删除
Redis作为消息队列：
· 如果你的需求是快产快消的即时消费场景，并且生产的消息立即被消费者消费掉。
· 如果速度是你十分看重的，比如慢了一秒好几千万这种。
· 如果允许出现消息丢失的场景。
· 如果你不需要系统保存你发送过的消息。
· 如果需要处理的数据量并不是那么巨大。
其他消息队列：
· 如果你想要稳定的消息队列。
· 如果你想要你发送过的消息可以保留一定的时间，并不是无迹可寻的时候。
· 如果你无法忍受数据的丢失。
· 如果速度不需要那么的快。
· 如果需要处理数据量巨大的时候。
应用场景分析
Redis：轻量级，高并发，延迟敏感即时数据分析、秒杀计数器、缓存等。
其他MQ：重量级，高并发，异步批量数据异步处理、并行任务串行化，高负载任务的负载均衡等。
redis是单线程的，为什么那么快?- 完全基于内存
- i/o多路复用
- 数据结构简单
- 拥有自己的协议-Redis 序列化协议
CAP定理?一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败.
redis和zookeeper分布式锁,哪个性能更高?在分布式系统中,可用性、一致性、分区容错性不能同时被满足,P必须满足,剩下的根据业务从AC中选一个
- redis的性能优于zookeeper
- redis是基于内存的
- zookeeper需要进行节点数据通过 至少需要两次io
