·····················································
RPC和HTTP的比较
HTTP 和 RPC 其实是两个维度的东西， HTTP 指的是通信协议。
而 RPC 则是远程调用，其对应的是本地调用。
RPC 的通信可以用 HTTP 协议，也可以自定义协议，是不做约束的。
可能你常听到什么什么之间是 RPC 调用的，那你有没有想过为什么要 RPC， 我们直接 WebClient HTTP 调用不行么？
其实 RPC 调用是因为服务的拆分，或者本身公司内部的多个服务之间的通信。
服务的拆分独立部署，那服务间的调用就必然需要网络通信，用 WebClient 调用当然可行，但是比较麻烦。
我们想即使服务被拆分了但是使用起来还是和之前本地调用一样方便。
所以就出现了 RPC 框架，来屏蔽这些底层调用细节，使得我们编码上还是和之前本地调用相差不多。
并且 HTTP 协议比较的冗余，RPC 都是内部调用所以不需要太考虑通用性，只要公司内部保持格式统一即可。
所以可以做各种定制化的协议来使得通信更高效。
比如规定 yes 代表 yes的练级攻略，你看是不是更高效了，少传输的 5 个字。
就像特殊行动的暗号，高效简洁！
所以公司内部服务的调用一般都用 RPC，而 HTTP 的优势在于通用，大家都认可这个协议。
所以三方平台提供的接口都是通过 HTTP 协议调用的。
所以现在知道为什么我们调用第三方都是 HTTP ，公司内部用 RPC 了吧？
对了。
为什么要进行序列化
总结来说，序列化就是将对象转换成二进制数据的过程，而反序列就是反过来将二进制转换为对象的过程。
那么 RPC 框架为什么需要序列化呢？还是请你回想下 RPC 的通信流程：
不妨借用个例子帮助你理解，比如发快递，我们要发一个需要自行组装的物件。发件人发之前，会把物件拆开装箱，这就好比序列化；这时候快递员来了，不能磕碰呀，那就要打包，这就好比将序列化后的数据进行编码，封装成一个固定格式的协议；过了两天，收件人收到包裹了，就会拆箱将物件拼接好，这就好比是协议解码和反序列化。
所以现在你清楚了吗？因为网络传输的数据必须是二进制数据，所以在 RPC 调用中，对入参对象与返回值对象进行序列化与反序列化是一个必须的过程。
epoll与select、poll的比较
相对select来说, epoll的跨平台性不够用 只能工作在linux下, 而select可以在windows linux apple上使用, 还有手机端android iOS之类的都可以. android虽然是linux的内核 但早期版本同样不支持epoll的.
相对select来说 还是用起来还是复杂了一些, 不过和IOCP比起来 增加了一点点的复杂度却基本上达到了IOCP的并发量和性能, 而复杂度远远小于IOCP.
相对IOCP来说 对多核/多线程的支持不够好, 性能也因此在性能要求比较苛刻的情况下不如IOCP.
三次握手四次挥手
1.在链路层，由以太网的物理特性决定了数据帧的长度为(46＋18)－(1500＋18)，其中的18是数据帧的头和尾，也就是说数据帧的内容最大为1500(不包括帧头和帧尾)，即MTU(Maximum Transmission Unit)为1500；
2.在网络层，因为IP包的首部要占用20字节，所以这的MTU为1500－20＝1480；
3.在传输层，对于UDP包的首部要占用8字节，所以这的MTU为1480－8＝1472；
所以，在应用层，你的Data最大长度为1472。当我们的UDP包中的数据多于MTU(1472)时，发送方的IP层需要分片fragmentation进行传输，而在接收方IP层则需要进行数据报重组，由于UDP是不可靠的传输协议，如果分片丢失导致重组失败，将导致UDP数据包被丢弃。
从上面的分析来看，在普通的局域网环境下，UDP的数据最大为1472字节最好(避免分片重组)。
但在网络编程中，Internet中的路由器可能有设置成不同的值(小于默认值)，Internet上的标准MTU值为576，所以Internet的UDP编程时数据长度最好在576－20－8＝548字节以内。
mysql事务以及相应的保证
Redis 缓存
https://leslieaibin.github.io/2021/09/29/Redis/Redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
