kenttanl / idocuments Goto Github PK

• Sonarqube: https://github.com/SonarSource/sonarqube
• Jenkins: https://github.com/jenkinsci/jenkins

新的条目:

NoSQL:

• Memcached
• Cassandra
• Tair
• EVCache
• Aerospike
• Feed

服务发现与配置

• Consul

WEB Server

• OpenResty
• Apache httpd
• Tengine
• HAProxy

Druid、Kylin、Presto、Impala

• filebeat
• kubesphere

NPM 设置成淘宝的源：

# 默认地址为：https://registry.npmjs.org
npm config set registry https://registry.npm.taobao.org 

YARN 设置成淘宝的源：

yarn config set registry https://registry.npm.taobao.org

NPM 关闭 SSL：

npm config set strict-ssl false

• LVS
• Keepalived
• TSDB
• ClickHouse
• 索引数据结构的动画演示：B+ Tree, B Tree

通过 Wireshark 抓包以及 Debug 源码，对 Consumer poll 及 rebalance 相关操作得出以下结论：

1. new KafkaConsumer() 以及调用 consumer.subscribe() 方法时不会产生实际的 TCP 连接；
2. 只要在需要从服务器获取信息时，才会通过一个叫 Fetcher 的代理类去连接服务器，并执行所需的操作；
3. 只有调用 consumer.poll(...) 方法后，才会启动心跳线程。同时将 consumer 加入到 group 中，也即是此时才会进行 rebalance 操作；
4. 调用 consumer.poll(...) 操作时，实际执行了如下操作：
   • 1) 确保 coordinator 准备就绪；
   • 2) 确保该 group 处于活动状态；
     • 2.1) 确保 coordinator 准备就绪；
     • 2.2) 启动心跳线程（如果有必要）；
     • 2.3) 加入 Group（如果需要，此时应该就是由服务器进行 rebalance 操作了）；
   • 3) 检查心跳的状态，并指示客户端的活动状态（并未真正提交心跳，只是更改了心跳类中的一些指标数据。心跳由心跳线程轮询提交）；
   • 4) 自动提交 offset（如果有必要则进行异步提交）；
   • 5) 拉取并返回数据；

定义

TCP 是一个面向有连接的、可靠的通信服务协议

连接

• 为什么需要三次握手：
  1. 为了实现可靠的数据传输，TCP 协议的通信双方都必须维护一个序列号（Sequence number），以标识已经发送出去的数据包中，哪些是已经被对方收到的。所以三次握手的过程是通信双方相互告知与确认序列号起始值的必经步骤。如果只是两次握手，则至多只有连接发起方的其实序列号能够被确认；
  2. 为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误；
     
• 为什么序列号不从 0 开始：
  1. 预防 TCP 序列预测攻击，参考：https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack；
  2. 尽可能的避免数据混淆（2msl可以解决）；
• 为什么需要四次挥手：TCP 是全双工通讯协议，关闭连接时，服务器端收到对方的 FIN 报文，仅代表对方不在发送数据了，但是还是能够接受数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

数据的发送

• 保证可靠性传输的机制：通过校验和（Checksum）、序列号（Seq）、确认应答（Ack）、重发控制、连接管理、窗口控制等机制实现可靠性传输；
• 单位：TCP 以段为单位发送数据，每段消息的最大长度被称为 MSS（Maximum Segment Size）,MSS 是在三次握手通过双方协商而成（选择两者中相对更小的值）；
• 可靠性：数据的发送通过序列号与确认应答来提高其可靠性：如果发送端在一定的时间内没有等到确认应答，那么发送端会认为数据已经丢失，并进行重发。由此可以保证，即使产生了丢包，仍然能够将数据发送出去；
• 重发超时如何确定：每次发包时都会计算往返时间及其偏差，将这个往返时间和偏差相加，重发超时时间就是比这个总和要稍微大一点的值；
• 滑动窗口控制：通过窗口提高发送速，其类似于阻塞队列似的缓冲区，以使得发送数据时不必每次发送完消息都必须等待应答后才能继续发送下一次的消息。同时确认应答也不再是以每个分段，而是以更大的单位进行确认时，转发时间将会被大幅度的缩短。窗口的滑动是在收到确认应答后，将窗口滑动到确认应答中的序列号的位置。
• 窗口控制与重发控制：发送端仅需要通过最后一次确认序列号来确定哪些消息发送成功了，而不必对所有没有收到确认应答的数据都进行重；
• 流控制：
  1. 动态调整窗口大小：接收端可以根据自己的实际接受能力动态的来向发送端告知自己可以接受数据的大小，发送端收到后，发送的数据不会超过这个大小；
  2. 窗口探测：为了避免缓冲区满了之后，无法继续发送数据的同时更新窗口大小的通知被丢失，此时发送端会时不时的发送一个叫做窗口探测的数据段，此数据仅包含一个字节以获取最新的窗口大小信息。
• 拥塞控制：
  1. 慢启动：即初始窗口（拥塞窗口）大小为1MSS，然后的大小每收到一次确认应答就增加1，最终发送端能够发送的数据是接收端通知的窗口大小与拥塞窗口的大小中较小值还要小的值；
  2. 慢启动阈值：如果拥塞窗口的值超出这个阈值，在每收到一次确认应答时，只允许以下面这种比例方法拥塞窗口：1个数据段的字节数 / 拥塞窗口（字节） * 1个数据段字节数
• 提高网络利用率的一些规范：
  1. Nagle 算法：如果发送端还有应该发送的数据，但是这部分数据很少的话，则进行延迟发送的一种处理机制；
  2. 延迟确认应答：接收端收到数据以后，并不立即返回确认应答，而是延迟一段时间，从而减少应答数量；
  3. 捎带应答：确认应答和回执数据通过一个包发送的方式，即回执数据时捎带了一个应答。这样可以减少包的发送次数；

For WEB Test:

• Serenity BDD
• Katalon

• Spinnaker
• Nacos

在 Maven 的 Setting.xml 文件中的 mirrors 节点下配置 mirror，如下：

<mirrors>
  <mirror>
      <id>alimaven</id>
      <name>aliyun maven</name>
      <url>http://maven.aliyun.com/nexus/content/groups/public/</url>
      <mirrorOf>central</mirrorOf>        
    </mirror>
</mirrors>

整理一些典型的架构或模式，例：

• Shared-disk
• Shard-nothing
• Shard-everything
• Active/standby 主备模式
• Master-slave 主从架构
• Pipe-filter 管道-过滤器模式
• Event-bus 事件总线模式
• Peer-to-peer (P2P) 点对点架构
• Broker mode
• Service Mesh 服务网格
• Sidecar mode 边车模式

For Java

• IDEA
• JDK
• Maven
• JADX
• MAT (JavaHeapAnalyzer)
• JHA (MemoryAnalyzerTool)

For FrontEnd/Angular

• VS Code
• Node.js/npm/Yarn
• @angular\cli
• python2

For DB

• SQLlog: for MySQL
• SSMS: for SQLServer

For Linux

• MobeXterm: SSH
• FileZilla: file transfer

Others

• Git
• KafkaTool
• KeePass
• Postman
• Findder
• Wireshark
• Draw.io
• Sublime Text
• XMind
• Devart Code Compare
• Everything
• PilotEdit
• 7-Zip