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 PATH=$F...

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

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

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

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

根据加锁粒度，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技术（Windows也有类...

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

1.1 服务注册中心是啥？ 用来实现微服务实例的自动注册与发现。 1.2 没有注册中心时 若服务依赖如下：  服务还不是很多，于是很多人就把各服务节点直接放进一个全局的配置文件 A 服务的全部 host B 服务的全部 host ...将该文件放在每个服务的远程配置中心或者本地配置文件中维护。当变更时，只有确实需要改变的服务团队才会修改其配置文件，最后就变成：  需全局配置文件 各模块各自维护  变更时就很不方便，每当服务扩缩容需更改配置时，很多服务都要跟着变更，团队之间沟通成本高，上线风险大。 于是，催生了注册中心。 1.3 注册中心的主要功能  1.3.1 服务注册 Provider将自身...

Enterprise JavaBeans（EJB）和Java的远程方法调用（RMI）仅限于Java 分布式组件对象模型（DCOM）仅限于Microsoft平台 公共对象请求代理体系结构（CORBA）过于复杂，不提供前向或后向兼容性  所有这些都是基于诞生自1970s的远程过程调用（RPC）思想。 RPC模型试图向远程网络服务发出请求，看起来与在同一进程中调用编程语言的方法相同（这种抽象称为位置透明）。尽管RPC起初看起来很方便，但这种方法根本上是有缺陷的。网络请求与本地函数调用很不同：  本地方法调用可预测，且成功或失败仅取决于控制的参数。网络请求不可预知：由于网络问题，请求或响应可能会丢失，...