全局异常处理：
自定义异常：
统一捕获并处理异常，避免多处的try catch
Java每个线程都有一个异常捕获器，重写这个捕获器的回调
尽量不要用Exception，只catch可预估的异常种类，千万不要吃掉异常
UncaughtExceptionHandler
-------------------------------------------------------------------------
重试框架Guava-Retry和spring-Retry
https://blog.csdn.net/zzzgd_666/article/details/84377962
https://blog.csdn.net/zzzgd_666/article/details/80494540
https://blog.csdn.net/zzzgd_666/article/details/80718061
https://blog.csdn.net/zzzgd_666/article/details/92078433
https://blog.csdn.net/zzzgd_666/article/details/81544098
-------------------------------------------------------------------------
Kafka需要注意点：
- topic的划分，大topic对生产者有利且维护成本低，小topic对消费者比较友好。如果是完全不相关的相关数据源且topic数不是发散的，优先考虑分topic。
- Kafka的并行单位是partition，partition数目直接关系整体的吞吐量，但parition数并不是越大越高，3个partition就能吃满一块普通硬盘IO了。所以partition数是由数据规模决定，最终还是需要硬盘来抗。
- partition key选择不当，可能会造成数据倾斜。在对数据有顺序性要求才需使用partition key。Kafka的producer sdk在没指定partition key时，在一定时间内只会往一个partition写数据，这种情况下当producer数少于partition数也会造成数据倾斜，可以提高producer数目来解决这个问题。
-------------------------------------------------------------------------
mysql使用整型存储IP
https://www.cnblogs.com/hustcat/archive/2009/10/28/1591648.html
(1)越小的数据类型通常更好：越小的数据类型通常在磁盘、内存和CPU缓存中都需要更少的空间，处理起来更快。
(2)简单的数据类型更好：整型数据比起字符，处理开销更小，因为字符串的比较更复杂。在MySQL中，应该用内置的日期和时间数据类型，而不是用字符串来存储时间；以及用整型数据类型存储IP地址。
(3)尽量避免NULL：应该指定列为NOT NULL，除非你想存储NULL。在MySQL中，含有空值的列很难进行查询优化，因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值。
select inet_aton('127.0.0.1') from dual;
select inet_ntoa(2130706433) from dual;
-------------------------------------------------------------------------
mysql的format:
https://blog.csdn.net/lsjseu/article/details/51887991
在
mysql中， 若一张表里面不存在varchar、text以及其变形、blob以及其变形的字段的话，那么张这个表其实也叫静态表，即该表的row_format是fixed，就是说每条记录所占用的字节一样。其优点读取快，缺点浪费额外一部分空间。
若一张表里面存在varchar、text以及其变形、blob以及其变形的字段的话，那么张这个表其实也叫动态表，即该表的row_format是dynamic，就是说每条记录所占用的字节是动态的。其优点节省空间，缺点增加读取的时间开销。
所以，做搜索查询量大的表一般都以空间来换取时间，设计成静态表。
mysql常用存储格式：
DEFAULT
FIXED
DYNAMIC
COMPRESSED
REDUNDANT
COMPACT
修改mysql行格式：
ALTER TABLE table_name ROW_FORMAT = DEFAULT
fixed--->dynamic: 这会导致CHAR变成VARCHAR
dynamic--->fixed: 这会导致VARCHAR变成CHAR
-------------------------------------------------------------------------
https://www.2cto.com/database/201411/351106.html
使用B-tree结构可以显著减少定位记录时所经历的中间过程，从而加快存取速度。
B+tree是B-tree的一个变种，大名鼎鼎的MySQL就普遍使用B+tree实现其索引结构。
一般来说，索引本身也很大，不可能全部存储在内存中，因此索引往往以索引文件的形式存储的磁盘上。这样的话，索引查找过程中就要产生磁盘I/O消耗，相对于内存存取，I/O存取的消耗要高几个数量级，所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的渐进复杂度。换句话说，索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数。
为了达到这个目的，磁盘按需读取，要求每次都会预读的长度一般为页的整数倍。而且数据库系统将一个节点的大小设为等于一个页，这样每个节点只需要一次I/O就可以完全载入。每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个node只需一次I/O。并把B-tree中的m值设的非常大，就会让树的高度降低，有利于一次完全载入
-------------------------------------------------------------------------
https://blog.csdn.net/DoUUnderstand/article/details/70215061
聚簇索引：索引的叶节点就是数据节点。
非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。
聚集索引：指索引项的排序方式和表中数据记录排序方式一致的索引
也就是说聚集索引的顺序就是数据的物理存储顺序。它会根据聚集索引键的顺序来存储表中的数据，即对表的数据按索引键的顺序进行排序，然后重新存储到磁盘上。因为数据在物理存放时只能有一种排列方式，所以一个表只能有一个聚集索引。
由于聚集索引规定数据在表中的物理存储顺序，因此一个表只能包含一个聚集索引。但该索引可以包含多个列（组合索引），就像电话簿按姓氏和名字进行组织一样
聚簇索引并不是一种单独的索引类型，而是一种数据存储方式。术语“聚族”表示数据行和相邻的键值紧凑的存储在一起。因为无法同时把数据行放在两个不同的地方，所以一个表只能有一个聚族索引。
聚集索引对于那些经常要搜索范围值的列特别有效。使用聚集索引找到包含第一个值的行后，便可以确保包含后续索引值的行在物理相邻。
聚集索引会降低 insert，和update操作的性能，所以，是否使用聚集索引要全面衡量
数据访问更快。聚族索引将索引和数据保存在同一个B-Tree中，因此从聚族索引中获取数据通常比在非聚族索引中查找更快
非聚集索引： 索引顺序与物理存储顺序不同
非聚集索引的使用场合为：
a.查询所获数据量较少时；
b.某字段中的数据的唯一性比较高时；
非聚集索引必须是稠密索引
-------------------------------------------------------------------------
重要需要细看
https://www.2cto.com/database/201411/351106.html
-------------------------------------------------------------------------
可以看此人博客
https://blog.csdn.net/DoUUnderstand
-------------------------------------------------------------------------
https://www.cnblogs.com/vianzhang/p/7922426.html
B+树
-------------------------------------------------------------------------
MySQL InnoDB默认Row-Level Lock，所以只有「明确」地指定主键，MySQL 才会执行Row lock (只锁住被选取的数据) ，否则MySQL 将会执行Table Lock (将整个数据表单给锁住)。
-------------------------------------------------------------------------
https://www.cnblogs.com/shaohef/p/4499881.html
二阶段提交和三阶段提交都是这样的一致性算法。但是一般的算法比如二阶段提交，要求所有的参与节点都通过了才能完成事务，任意节点失去联系都会导致整个事务的阻塞。三阶段提交为事务设置了超时阶段，即使一段时间内没有来自Coordinator的指示，也能自行提交事务，三阶段提交的问题是无法应对网络分区。网络分区在一个线上系统的实际运行中是很常见的，比如交换机的某个口坏了，或者路由器配错了，再或者网络拥塞导致时延变大，对网络应用来说，是无法区别只是时延变大了还是网络断了。分区发生时，数据中心的整个网络暂时被分成几块互相不能通信的小网络，这个时候三阶段提交有可能在不同的小网络里提交不同的事务，导致不一致的出现。而且三阶段提交对每个事务都需要3次交互，时延太长。Paxos算法的先进之处在于，当且仅当大多数成员达成一致时提交事务，即使网络被分区，每个分区内的集群成员不足整个集群的多数时，就不会提交事务，反之只要分区内的节点能达到多数要求，系统就能继续运行下去。Paxos算法既不会出现二阶段提交的阻塞情况，也没有三阶段提交的不一致的风险。
-------------------------------------------------------------------------
-------------------------------------------------------------------------
-------------------------------------------------------------------------
-------------------------------------------------------------------------
浙公网安备 33010602011771号