硬核

很硬核的干货

RESAR性能工程中，场景分为基准、容量、稳定性、异常。每类场景对应不同目标。基准场景是为找到系统中明显配置及软件Bug，也为容量场景提供可对比的基准数据。基准场景要有确定结论。线程数应该如何确定，压力线程的连续递增的重要性，以及如何将之前所讲的分析思路应用在具体的分析案例中。1 性能场景分类通常拿到的需求：评估系统能支持的最大容量。为知道当前的系统容量，目标很明确测试并优化系统以支持线上业务。有优化必要测试并评估未来几年内，性能容量是否满足业务发展。要求测试未来业务场景把场景按照目标划分三类：验证：评估当前系统容量调优：评估并优化当前系统推算：评估并推算未来系统容量这种分类和我们一直强调的按...

1 本地安装只需几个简单的步骤即可启动并运行Flink示例程序。1.1 安装：下载并启动Flink唯一要求是装有Java 8，检查Java正确安装：直接下载二进制包到本地并解压。2 配置 flink-conf.yamljobmanager.rpc.address: 10.0.0.1 配置主节点的ipjobmanager 主节点taskmanager 从节点配置. bash_profile vim ~/.bash_profile # Flink export FLINK_HOME=/Users/javaedge/Downloads/soft/flink-1.17.0 export P...

1 主动原则：主动做事 工作要积极主动，刚进入职场的同学，以为“服从命令听指挥”“领导指哪打哪”就是积极主动，结果易养 1.1 不好习惯 ① 认为主管肯定会帮你搞定晋升 你可能非常信任主管，认为自己只要把主管安排的任务做好，晋升就是水到渠成的事情。所以你就算觉得现在分配的任务对自己的成长帮助不大，也不会主动跟主管沟通，而是认为“他这么安排肯定是有道理的”“也许过一段时间他就会给我安排新的任务”。这其实是不对的。 首先，不是每个主管都会关注组员的成长。主管做事风格可能多种： 有的主管特别关注业务目标是否达成，所以会花很多时间跟产品经理和项目经理沟通交流 有的主管特别关注团队形象，要求所有对外承...

异常重试的意义发起一次RPC调用，调用远程的一个服务，如用户的登录操作，先对用户的用户名以及密码进行验证，验证成功后，获取用户基本信息。通过远程的用户服务获取用户基本信息时，恰好网络故障，如突然抖了一下，导致请求失败，而这请求我们希望它能够尽可能执行成功，咋办？需重新发起一次RPC调用，代码中如何处理？catch一下，失败就再发起一次调用？这显然不优雅。考虑RPC框架的重试机制。2 RPC框架的重试机制当调用端发起的请求失败时，RPC框架自身可进行重试，再重新发请求，用户可自行设置：是否开启重试重试次数RPC异常重试：调用端在发起RPC调用时，会经过负载均衡，选择一个节点，之后它会向这个节点发...

1 kafka说kafka延迟比rocketmq延迟高 是有一个前提的 就是topic较多的时候 这个和这2个MQ的数据存储结构有关系的 在topic少的时候延迟基本一致。kafka的数据存储结构设计师尽可能的保证吞吐量，所以在设计时是尽可能保证log日志小，它的数据结构如下 其中topic只是逻辑概念，分区对应就是一个物理文件夹：所以topic很多时，分区文件数量会很庞大，磁盘顺序读效率变得低下，则会在topic比较多时，磁盘顺序读就蜕变为随机读，延迟就高了。即 kafka 性能对于topic 有阈值（20 个）。2 RockertMQ淘宝业务比较复杂，topic很多，为解决这痛点，...

从以下两个细节，大概率可以进行有效判断，百试百灵。 细节一：当你在工作过程中犯了错，得罪了甲方时，看领导怎么处理。如果领导根本不当回事，甚至主动开导你，那么大概率，领导是在培养你。 细节二：当你的领导被更上级领导或者老板训了的时候，看领导怎么处理。如果领导没有把负能量传递给你，甚至鼓励你，那么大概率，领导是在培养你。碰到这样的领导，不容易。

根据加锁粒度，MySQL的锁： 全局锁 表级锁 行锁 全局锁和表锁都实现在Server层。 1 全局锁 对整个DB实例加锁。 1.1 加全局的读锁 执行命令： Flush tables with read lock (FTWRL) 让整个库只读，之后其他线程的如下语句会被阻塞： 数据更新语句（数据的增删改） 数据定义语句（建表、修改表结构等） 更新类事务的提交语句 若FTWRL前有读写，FTWRL都会等待读写执行完毕后再执行。 FTWRL执行时，要刷脏页数据到磁盘，因为要保持数据一致性，所以执行FTWRL的时机是所有事务都提交完毕后。 1.2 适用场景 - 全库逻辑备份 把整库的每个表...

1 Namespace 1.1 容器为何需要进程隔离 被其他容器修改文件，导致安全问题 资源的并发写入导致不一致性 资源的抢占，导致其他容器被影响 docker run -it --name demo_docker busybox /bin/sh / # ps -ef 在宿主机查看进程ID ps -ef|grep busybox真实的 docker 容器 pid 这就是进程资源隔离表象： 对宿主机， docker run 启动的只是个进程，pid=44451 而容器程序本身被隔离了，容器的内部都只能看到自己内部的进程 这其实是基于Linux的Namespace技术（W...

屏幕内容决定了工程师级别哦