实习问题总结

为什么使用GRPC作为通信方式，对比如REST好处在哪里？

• 使用protobuf作为序列化格式，以二进制进行传输，减小了数据包的大小，效率高
  •  proto强类型定义、支持复杂数据类型，编译运行可以进行严格的数据验证，每个字段都有唯一编号，作为序列化和反序列化的依据
  • JSON便于阅读，没有强类型约束，通过键序列化和反序列化
  • proto二进制，空间小，效率高，解析速度快
  • 更适合高性能，强类型系统
• 支持HTTP2，本身HTTP2就是字节传输，多路复用、首部压缩，提高了传输性能和并发处理能力。
• 强类型定义：通过.proto定义服务和消息格式，提供了强类型的接口定义，减少了编码错误和解析错误。
• .proto自动生成服务端、客户端代码
• 语言支持广泛，在里面主要是kotlin、python、C++
• 双向流通信：实现长连接和实时数据传输
• 内置SSL/TLS支持
• 对比于REST：二进制HTTP2优于REST的文本格式和HTTP/1.1
  • 强类型，REST缺乏类型约束
  • 支持流式通信，REST基于请求/响应模型，2.0也是
• 更适用于对性能和传输效率要求较高的双向通信

SharedFlow和Flow？

• 对于shardflow来说，有缓冲区，独立于收集器。
• 对于flow来说，除了collect类似的操作（只有collect才能emit），其他只是定义这个流的行为，而不是真正执行，没有缓冲区，每次收集都是重新去操作。看下面重要代码

• MutableSharedFlow的三种缓冲策略

• 

• 

websocket也可以实现？

• 确实websocket也支持长连接的双向通信，服务端也能主动推送消息，也有WAMP框架，基于发布/订阅，但是GPPC性能更高，同时proto支持强类型定义，
• 实现和维护更复杂，需要处理连接管理、心跳检测、重连这些问题。
• HTTP2的头部压缩，服务器推送、多路复用，完美契合grpc对于高效通信的需求

Why RockDB？

• 在流处理和实时分析中，kafka的streams，RocksDB 常用作状态存储，实时存储和更新流数据的处理状态。适合需要高性能、持久化存储和高吞吐量的流处理应用。
• 提供了键值对操作
• 支持范围写范围查找，因为提供了迭代器
• 日志结构合并树 （LSM-Tree）
• MemTable：内存中的一个有序查找表（比如：红黑树），用于缓存最近的写入操作。当MemTable达到一定大小时，其内容会被刷新（flush）到磁盘上的SSTable中。
• SSTable（Sorted String Table）：这是一