doc[zfoo]: 更新文档

2026-08-18 06:27:01 +00:00 · 2021-10-10 22:52:11 +08:00
parent 5cb953f4e8
commit a72746c4c1
2 changed files with 7 additions and 6 deletions
@@ -59,18 +59,18 @@ cpu： i9900k

 - 为了代码的优雅，zfoo protocol要求全部的协议类都要继承IPacket，但是可以保证不损失性能的情况下支持不继承IPacket的设计，这个有待继续讨论。
 - 协议类修改
-
+  - 修改字段名称过后无法解析，内部使用字段的名称按照字符串的自然顺序来依次读写的，所以修改名称会导致读写顺序变化导致出现异常
+  - 减少字段无法解析，没必要一定要删除一个不需要的字段，所以不考虑这种情况
+  - 增加字段无法解析，可以考虑通过版本号去控制，或者增加新的协议类去解决（组合大于继承，协议类应该对扩展开放，对修改关闭）
 ```
-协议类属性名称修改过后无法解析，内部使用属性的名称按照字符串的自然顺序来依次读写的，所以修改属性的名称会导致读写顺序变化导致出现异常
-协议类减少字段无法解析，字段不用了，就放在那不赋值就可以，没必要一定要删除，可以等到下个大版本更新再去删除，所以主要考虑增加字段的情况
-协议类增加字段无法解析，这套框架是为通信设计的协议，增加字段服务器不更新也解析不出来新字段，既然服务器要更新为什么不通过版本号去控制？
+设计模式六大原则中的开闭原则是对扩展开放，对修改关闭。协议的设计涉及到功能应该也要遵守这个原则。

 目前的序列化过后对象的大小如下：
 简单对象，zfoo包体大小8，kryo包体大小5，protobuf包体大小8
 常规对象，zfoo包体大小547，kryo包体大小594，protobuf包体大小984
 复杂对象，zfoo包体大小2214，kryo包体大小2525，protobuf包体大小5091

-如果考虑支持修改协议类属性名称，必须让字段的读写顺序可控，这就需要注解来标识属性的顺序（protostuff就是这样做的），但是感觉这样不优雅。
+如果考虑支持修改协议类字段名称，必须让字段的读写顺序可控，这就需要注解来标识字段的顺序（protostuff就是这样做的），但是感觉这样不优雅。
 如果考虑支持字段增加和减少，需要消耗5%左右的性能（预估），并且增加一倍的包体积大小（写入字段的顺序），感觉不是非常划算。
 因为可以通过协议版本号来解决这个问题，所以去支持这样的增删操作动力并不是非常的大。

@@ -1,8 +1,9 @@
 ### Ⅰ. 注意事项

- 轻量级的cron表达式实现，时间可以向前调，也可以向后调，都会出发trigger
+- 轻量级的cron表达式实现
 - 每秒钟执行一次SchedulerManager.triggerPerSecond()方法，循环遍历可执行的scheduler
 - SchedulerManager的executor只有一条线程，所以使用者要避免做耗时和阻塞的运算，如果有这样的需求可以抛到其它线程池
+- 最大亮点是前后调整本地机器时间都会触发任务调度，本地开发非常有用。java和spring自带的任务调度不支持调整机器时间

 ### Ⅱ. Cron Expression Example