Algorithm
两类查找问题（Set 和 Map）
Set用于查找有无 （检查是否存在、去重问题）
Map用户查找对应关系（设置频次）
349.Intersection of Two Arrays
350.Intersection of Two Arrays II
242.Valid Anagram
75.Sort Colors
202.Happy Number
1.Two Sum
219.Contains Duplicate II (set + 滑动窗口)
Review
一、《Flink Table API编程》
讲解了TableApi 比SQl 新增的易用性和功能性操作。
例如：
Columns Operation ：AddColumns，AddOrReplaceColumns，DropColumns，RenameColumns
Columns Function ：withColumns(...)，withoutColumns(...)
Map operation :def map(scalarFunction: Expression): Table
FlatMap operation :def flatMap(tableFunction: Expression): Table
Aggregate operation
TableAggregate operation
二、《Flink Runtime核心机制剖析》
- Per-Job 和Sesson运行模式区别：PerJob独享Dispather和ResouceManager，按照需要申请资源，适合执行时间长的大作业。Session则是共享Dispater、RM和资源的适合小作业。
Tips/Technology
一、Kafka的重要参数设置
- Broker端
- log.dirs：指定Broker若干文件目录，无默认值。指定多块盘的好处是提高读写性能，在1.1版本后又故障转移能力。
- zookeeper.connect： 指定元数据zk路径 CSV格式。
- listeners：多个Brokers相互通信的参数，告诉外部连接着是通过什么协议访问主机名和端口访问Kafka服务。（建议全部使用主机名，否则可能发生无法连接的问题）
- Topic级别
- auto.create.topics.enable：是否允许自动创建Topic。建议为false
- unclean.leader.election.enable：是否允许Unclean Leader选举。建议为false，否则可能会丢数据。
- auto.leader.rebalance.enable：是否允许定期进行Leader选举。生产建议为false，换leader代价很高。
- 数据留存
- log.retention.{hour|minutes|ms}：这是个“三兄弟”，都是控制一条消息数据被保存多长时
间。从优先级上来说ms设置最高、minutes次之、hour最低。 - log.retention.bytes：这是指定Broker为消息保存的总磁盘容量大小。默认是-1就是不做限制，但防止云上恶意使用磁盘，可以设置。
- message.max.bytes：控制Broker能够接收的最大消息大小。默认不到1k，生产环境基本不够用要调大。
- JVM端
- 指定堆大小 建议6G 使用方法： export KAFKA_HEAP_OPTS=--Xms6g --Xmx6g
- 指定GC参数：jvm1.8建议G1回收器。使用方法：export KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC
- 操作系统
- 文件描述符限制： ulimit -n 1000000 否则动不动就来Too many open files错误。
- 文件系统类型：ext3，ext4，XFS，ZFS
- Swappiness：0或者1,防止kafka使用swap空间，使用1可以看到kafka性能急剧下降便于诊断问题。
- 提交时间。
二、Kafka中的分区
- 分布式系统中的叫法
Kafka中叫分区，在MongoDB和
Elasticsearch中就叫分片Shard，而在HBase中则叫Region，在Cassandra中又被称作vnode。叫法不同但原理一样。
- 分区策略
- 轮询策略
- 随机策略
- 按消息key保序策略
- 自定义策略 实现 org.apache.kafka.clients.producer.Partitioner
kafka中如果指定了Key，那么默认实现按消息键保序
策略；如果没有指定Key，则使用轮询策略。
三、Kafka中的压缩算法
- 指定方式： props.put("compression.type", "gzip");在生产端指定会卸载消息中如何Producer端压缩、Broker端保持、Consumer端解压缩。
-
算法对比
Facebook Zstandard提供
四、Kafka数据零丢失
- 丢失场景
- 生产者程序丢失：程序已经发送，kafka没有保存。原因是kafka发消息都是异步的，如果消息太大，或者网络抖动就没发上去。
- 消费者程序丢数据：消费者自动提交，kafka就认为已经被消费了。
- 最佳实践
- 生产者Api不要用producer.send(msg)，而要使用producer.send(msg, callback)。并设置retries使其自动重试。
- 设置acks=all ，保证所有副本Borker都接受到消息，该消息才算提交。
- 设置replication.factor >= 3，保证有充足的副本数
- 设置unclean.leader.election.enable = false。防止Broker落后Leader太多，然后被选上Leader导致数据丢失。
- 确保消息消费完成再提交。Consumer端有个参数enable.auto.commit，最好把它设置成false，并采用手
动提交位移的方式。 - 设置min.insync.replicas > 1。这依然是Broker端参数，控制的是消息至少要被写入到多少个副本才算
是“已提交”。设置成大于1可以提升消息持久性。在实际环境中千万不要使用默认值1。 - 确保replication.factor > min.insync.replicas。如果两者相等，那么只要有一个副本挂机，整个分区就无
法正常工作了。我们不仅要改善消息的持久性，防止数据丢失，还要在不降低可用性的基础上完成。推
荐设置成replication.factor = min.insync.replicas + 1。
五、Mysql整体架构
六、事务隔离机制
- 读未提交 （read uncommitted）：一个事务还没提交时，它做的变更就能被别的事务看到。
- 读提交 （read committed）：一个事务提交之后，它做的变更才会被其他事务看到。
- 可重复读 （repeatable read）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
- 串行化（serializable ），顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。
Oracle默认隔离级别是 READ-COMMITTED
MySQL默认隔离级别是 REPEATABLE-READ
实现原理：每条记录在更新的时候都会记录一条回滚操作，这个数据记录在回滚日志中。当在查询的时候不同事务会有不同的read-view。
Share
《薄世宁：医学通识》
- 生命是具有自我修复能力的，一切的医疗本质都是支持自我修复，包括给自我修复争取时间，等他自我修复发挥作用。
- 我们为什么会生病？答案就是科学发达了，我们活得寿命超过了细胞分裂的次数，疾病是人类进化的遗产。
- 要坚信任何病都有病理基础，不是凭空产生的，那么找到治病的办法只是时间问题。
- 疾病不是突然发生的，而是突然发现的。
- 真正的健康是暴露于细菌的危险之下，还依然健康。
Research
Flink 双流join,Kafka分区及参数，Mysql知识巩固
