2019-10-10今日得到
关键字:背压机制(back pressure)
当客户端同步请求服务端时，客户端需要等待服务端处理完请求并返回响应，在此期间，客户端需要等待，这是一种天然背压机制
那换成异步请求呢？
客户端异步请求服务端时，不会等待服务端处理请求，这样就丧失了同步请求的那种天然背压。
如果服务器处理请求的速度慢于客户端发送请求的速度，就会导致InFlightRequest(在途请求，即还未被服务端处理或响应的请求)越来越多，如果这些在途请求保存在内存中，就可能导致内存飙升，进而引发频繁FGC，之前线上遇到过几次FGC的案例【在公众号:每天晒白牙 中分享过一个vertx-redis-client客户端的案例 https://mp.weixin.qq.com/s/fWsy26VeUvb8yPKON3OTmA，后面也遇到rpc框架中也出现类似的问题】都是因为这些在途请求保存在一个无界队列中，请求得不到处理，导致内存占用过高。
想要避免上面的情况，需要我们主动引入背压机制，即在服务端处理不过来的情况要限制客户端的请求速率，具体的做法应该有很多，我列举几个
1.把无界队列换成有界队列，队列满了就不让添加了
2.在往队列中添加请求的时候获取许可，服务端处理完请求释放许可，如果许可没了就阻塞客户端的请求或返回异常
——每天晒白牙展开 4
2019-11-02使用fastjson实现，改动代码见：https://gist.github.com/Switch-vov/8cb76aabd1e1addcdbec205cc06d9023作者回复: 赞交作业的同学👍
3
2019-11-14requestId要保持唯一性，不然消息就乱了！！而且不用保持全局唯一性，只要保证在单个服务中唯一就好
2019-11-06想用json的方式，搞一个泛型的CommonSerializer<T>出来，序列化好说，但是在进行解析成对象的时候，发现我通过泛型无法拿到原本的Class，😂，想了半天方法用反射去搞，但是觉得这样不好，查了一下发现一般这种情况是通过传入一个你想要解析的最终类型的Class对象，但是又要求不该接口，这样我就不能传进去一个Class，无奈，只能针对每个类型实现一下Serializer接口
2019-10-30有一点不是很理解，为啥typeMap不可以是(type, serializer)，通过type获取序列化实现类一步操作，现在看源码是通过type拿到class，再class拿到serializer作者回复: 这样保存也是可以的，因为我们用二个map，也就是二对儿kv来保存三种数据（type， class和serializer），必然由一种数据要重复保存一下。
获取序列化实现类的时候，需要拿到class对象的目的是检查一下serializer和class对应的数据类型是否一致。
2019-10-18有点不理解，Server启动时，向NameService注册接口时，序列化对象是MetadataSerializer？作者回复: 是这样的。
2019-10-10动手动手，一定要动手，netty不熟，看起来吃力，但也收获满满，每明白一点都是进步～～～作者回复: 是这样的，一定要动手写代码。
2019-10-09使用JSON字符串进行序列化，String的序列化保持原样。MetaData和RpcRequest修改了size parse serialize函数 https://gist.github.com/WangYangA9/210ca898525832cba8ddd57ae1ae3d13作者回复: 👍👍👍
2019-10-09ResponseInvocation 这个类是相当于一个回调类的形式吧。“就是根据响应头中的 requestId，去在途请求 inFlightRequest 中查找对应的 ResponseFuture，设置返回值并结束这个 ResponseFuture 就可以了。”这里的设置返回值是指code码形式吗？这里的作用是还需要在返回给服务端确认收到吗？老师有空看看作者回复: 这里面的返回值不是状态码，而是RPC调用的返回值，比如我们这个HelloService中，这个返回值就是调用HelloServiceImpl.hello()方法的返回值。
1- 2019-10-08老师的课程很多地方让人茅塞顿开，感觉从高中毕业之后就再也没有过这种抽丝剥茧学习知识的感觉了。感谢带来这么好的课程
作者回复: 感谢，希望你能通过学习有收获，有提高。
2019-10-08准点研读了一遍，受益匪浅。明天利用空闲时间尝试完成思考题。