index001
数据处理
目前在学习 ’机器学习’
获得徽章 1
- #青训营笔记创作活动#
2月17日 打卡day12
今日学习sql语句执行过程:
①先将SQL发送给SQL接口，SQL接口会对SQL语句进行哈希处理。
②SQL接口在缓存中根据哈希值检索数据，如果缓存中有则直接返回数据。
③缓存中未命中时会将SQL交给解析器，解析器会判断SQL语句是否正确：
• 错误：抛出1064错误码及相关的语法错误信息。 • 正确：将SQL语句交给优化器处理，进入第④步。
④优化器根据SQL制定出不同的执行方案，并择选出最优的执行计划。
⑤工作线程根据执行计划，调用存储引擎所提供的API获取数据。
⑥存储引擎根据API调用方的操作，去磁盘中检索数据
⑦发生磁盘IO后，对于磁盘中符合要求的数据逐条返回给SQL接口。
⑧SQL接口会对所有的结果集进行处理并返回。
展开评论点赞 - #青训营笔记创作活动#
2月14日 打卡day11
今日学习TCP&UDP
1. TCP为了实现可靠性，引入了重传机制、流量控制、滑动窗口、拥塞控制、分段以及乱序重排机制。而UDP则没有实现，因此一般来说TCP比UDP快。
2. TCP是面向连接的协议，而UDP是无连接的协议。这里的"连接"是操作系统内核在两端代码里维护的一套复杂状态机。
3. 大部分项目，会在基于UDP的基础上，模仿TCP，实现不同程度的可靠性机制。比如王者农药用的KCP其实就在基于UDP在应用层里实现了一套重传机制。
4. 对于UDP+重传的场景，如果要传超大数据包，并且没有实现分段机制的话，那数据就会在IP层分片，一旦丢包，那就需要重传整个超大数据包。而TCP则不需要考虑这个，内部会自动分段，丢包重传分段就行了。这种场景下，其实TCP更快。
展开评论点赞 - #青训营笔记创作活动#
2月13日 打卡day10
今日学习 https
TLS前期4次握手，本质上就是在利用非对称加密的特点，交换三个随机数。目的就是为了最后用这三个随机数生成对称加密的"会话秘钥"。后期就一直用对称机密的方式进行通信。因为非对称加密慢，对称加密相对来说快一些,所以不是都用非对称加密。整个TLS握手过程涉及2对私钥和公钥：
1. 服务器本身的公钥和私钥：在第二次握手中，服务器将自己的公钥（藏在数字证书里）发给客户端。第三次握手中用这个服务器公钥来加密第三个随机数 pre_master_key。服务器拿到后用自己的私钥去做解密。
2. CA的公钥和私钥：第二次握手中，传的数字证书里，包含了被CA的私钥加密过的服务器公钥。客户端拿到后，会用实现内置在操作系统或浏览器里的CA公钥去进行解密。
展开评论点赞 - #青训营笔记创作活动#
2月12日 打卡day9
今日学习websocket
1. TCP协议本身是全双工的，但我们最常用的HTTP1.1，虽然是基于TCP的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的websocket协议。
2. 正因为各个浏览器都支持HTTP协议，所以websocket会先利用HTTP协议加上一些特殊的header头进行握手升级操作，升级成功后就跟HTTP没有任何关系了，之后就用websocket的数据格式进行收发数据。
展开评论点赞 - #青训营笔记创作活动#
2月5日 打卡day8
今日学习
golang的优势
golang与java的对比，是重服务和重框架的对比。微服务失去了框架的束缚，各服务可以自由迭代，自由选择语言，自由替换，自由伸缩。容器和 Kubernetes 会保证这些服务的有序调度，ServicesMesh 会保证负载均衡、限流、健康检查、监控等一系列事项的正确运行。
微服务是一场架构层面的变革，而 Go 由于其简单实用的语法、编译快、可执行文件小等特点，是微服务所依赖的底层基础设施常用语言。
展开评论点赞 - #青训营笔记创作活动#
2月4日 打卡day7
今日学习
Goroutine和Channel知识点
1. 只要 Goroutine函数执行结束，或者执行返回，意味着 Goroutine的退出。如果 Goroutine
的函数或方法有返回值，在 Goroutine 退出时会将其忽略。
2. channel可以用于实现 Goroutine间的通信，也可以用来实现 Goroutine间的同步。
3. 无缓冲的 channel的发送与接收操作是同步的，在执行发送操作之后，对应 Goroutine
将会阻塞，直到有另一个 Goroutine去执行接收操作，反之亦然。
4. 通常只发送 channel类型和只接收 channel类型，会被用作函数的参数类型或返回值
5. 在 channel关闭之后，将不能对 channel执行发送操作，否则会发生 panic，提示 channel已关闭。
6. 关闭 channel之后，依旧可以对 channel执行接收操作，如果存在缓冲区的情况下，将会读取缓冲区的数据，如果缓冲区为空，则获取到的值为 channel对应类型的零值。
展开评论点赞 - #青训营笔记创作活动#
1月18日 打卡day6
今日学习
kitex是一个支持多协议的Golang RPC框架，从网络库、序列化库到框架的实现基本完全自研 的。对于治理平台、注册中心、配置中心、监控、链路跟踪、服务网格等微服务的治理，作为扩展放在一个 package 下。Kitex 仍然依赖内部的一些基础库。 bytedance/gopkg 库由 CloudWeGo 与字节跳动的语言团队合作维护，里面包含也了对 Golang 标准库能力的增强。
功能特性：
1. 支持Proxyless
2. JSON 和 Protobuf 泛化调用支持
目前Kitex的泛化主要针对后端的Thrift服务，无论是Protobuf、Map还是 JSON，Kitex 都会在调用端结合IDL解析，将这些数据映射编码为 Thrift 包发给后端服务。
3. 重试能力增强，支持超时重试和 Backup Request。
4. Thrift Validator生成校验代码
性能优化：
1. Thrift 高性能编解码
Frugal 是一 个 无需生成编解码代码、 基于 JIT 的高性能动态 Thrift 编解码器。
2. Protobuf 高性能编解码
使用 Kitex 的工具生成 Protobuf 的代码，就会默认生成 Fastpb 的编解码代码，在发起 RPC 调用的时候，Kitex 也会默认使用 Fastpb。无论是编码还是解码，在效率和内存分配上，Fastpb 都远远优于官方 Protobuf 序列化库。
3. gRPC性能优化展开评论点赞 - #青训营笔记创作活动#
1月17日 打卡day5
今日学习
自增ID和UUID的对比，以及雪花ID的优点。
使用自增ID，数据写入顺序和B+树索引的叶子节点顺序一致,不容易造成页分裂。
自增ID存在下述问题：
1.容易导致主键重复。比如导入旧数据时，线上又有新的数据新增，这时就有可能在导入时发生主键重复的异常。为了避免导入数据时出现主键重复的情况，要选择在应用停业后导入旧数据，导入完成后再启动应用。显然这样会造成不必要的麻烦。而UUID作为主键就不用担心这种情况。
2.不利于数据库的扩展。当采用自增id时，分库分表也会有主键重复的问题。UUID则不用担心这种问题。
雪花ID综合了自增ID和UUID的优点，有着全局唯一和有序递增的特点。
雪花ID是64bit的Long类型的ID
最高位是符号位，因为生成的 ID 总是正数，始终为0，不可用。
41位的时间序列，精确到毫秒级，41位的长度可以使用69年。时间位还有一个很重要的作用是可以根据时间进行排序。
10位的机器标识，10位的长度最多支持部署1024个节点。
12位的计数序列号，序列号即一系列的自增ID，可以支持同一节点同一毫秒生成多个ID序号，12位的计数序列号支持每个节点每毫秒产生4096个ID序号。展开评论点赞 - #青训营笔记创作活动#
1月16日 打卡day4
今日学习
学习mysql的B+树索引
1. Mysql 的表数据是以页的形式存放的，页在磁盘中不一定是连续的。
2. 页的空间是 16K, 并不是所有的空间都是用来存放数据的，会有一些固定的信息，如，页头，页尾，页码，校验码等等。
3. 索引结构不会影响单表最大行数，2kw 也只是推荐值，超过了这个值可能会导致 B + 树层级更高，影响查询性能。
4. 当B+树为3层，非叶子节点的子节点数量为1280，叶节点可以存放15条数据记录时，3层B+树可以存放的数据记录数为（1280 ^2） *15 = 24576000 （约 2.45kw）
展开评论点赞 - #青训营笔记创作活动#
1月15日 打卡day3
今日学习
常见的限流方式及其优缺点分析
1.计数器：
优点：固定时间段计数，实现简单，适用不太精准的场景；
缺点：对边界没有很好处理，导致限流不能精准控制。
2.滑动窗口：
优点：将固定时间段分块，时间比“计数器”复杂，适用于稍微精准的场景；
缺点：实现稍微复杂，还是不能彻底解决“计数器”存在的边界问题。
3.漏桶：
优点：可以很好的控制消费频率；
缺点：实现稍微复杂，单位时间内，不能多消费，感觉不太灵活。
4.令牌桶：
优点：可以解决“漏桶”不能灵活消费的问题，又能避免过渡消费，强烈推荐；
缺点：实现稍微复杂，其它缺点没有想到。
展开评论点赞