3.5 KiB
【E21现场】关于CN自动学习psiphon3 server ip写入TSG失败情况的客户反馈
| ID | Creation Date | Assignee | Status |
|---|---|---|---|
| OMPUB-922 | 2023-05-12T16:18:03.000+0800 | 刘洋 | 已关闭 |
对于2023-05-10下午遇到的16点psiphon动态学习ip界面列表未更新成功问题，跟客户沟通进展： 1.对于ip学习的列表的更新，客户认为删除和写入应该在一起，若是任何一个没成功都不应该commit. 2 对于锁表，客户觉得根据他的经验看来以当时删除和写入的量级不应该锁表。 3、对于意外未写入成功，应该继续提交写入，而不是只写入一次失败了就不继续提交了。
4、客户认为更新不正常，应该有回滚或者等等办法修复，目前情况16点失败一次后ip数量从70000左右变为50000多，一直都没恢复，他的领导一直要求他同步汇报ip学习数量进展，这怎么恢复。我告诉他，根据目前知道的删除逻辑，动态学习的ip会在几个小时后自动恢复。
5、客户希望了解自动学习的简单逻辑，希望提供功能文档。
目前客户暂未提供他具体都想知道哪些，现场还在等待客户提供他的需求详情。
zhangwei commented on 2023-05-26T16:42:57.110+0800:
-
方案一：由CN在每个周期请求CM API新增或者删除IP之前，请求Object查询接口获取其itemRows数量，如果数量超出或者少于评估数量，则本周期内不进行新增或者删除。但这种方式，如果遇到CM响应异常，CN对于新增IP或者删除IP，可能至少会存在一个周期的延迟。
-
方案二：CN在请求CM API新增或者删除IP时，如遇到CM响应异常，采用重试机制，重新请求CM API新增或者删除IP。最多重试次数或者重试间隔使用参数配置。
-
方案三：CM优化Object更新接口，支持Items按时间条件删除，同时批量新增Items，保证动态学习的Object更新的事务性，此逻辑优化可能对于CN在调用CM Object更新接口（同时新增IP和删除IP）的性能在TSG 22.11的基础上有一定性能降低。但CM考虑的优化版本在TSG 23.06。
zhangwei commented on 2023-05-31T10:51:20.676+0800:
{color:#525960}Maybe REST will be successful because it does not support transactions. Here is a quote from Roy Fielding, the guy who invented the term REST{color} {quote}If you find yourself in need of a distributed transaction protocol, then how can you possibly say that your architecture is based on REST? I simply cannot see how you can get from one situation (of using RESTful application state on the client and hypermedia to determine all state transitions) to the next situation of needing distributed agreement of transaction semantics wherein the client has to tell the server how to manage its own resources.
{color:#525960}...for now I consider "rest transaction" to be an oxymoron.{color} {quote} {color:#525960}REST架构本身并不支持事务，其标准之一”无状态“表示{color}每个请求都是独立的，互不关联{color:#525960}。在业务层面，如果资源操作的多次请求需事务控制，CM API需基于业务需求，设计接口层面的事务封装，包括事务发起，相同或者不同资源之间的多次操作请求接收与处理，事务提交。{color}
liuyang commented on 2023-09-25T13:42:47.808+0800:
目前现场采用方案二