为什么要用分布式锁？

[Zhonghua8]

为什么在com.alibaba.smart.framework.engine.service.command.impl.DefaultProcessCommandService#start(...)里要用分布式锁？
假设如果不用smart engine，同一个接口并发量很高要对同一个数据做修改，那也是业务开发人员需要考虑的事情，为什么在smart engine里要考虑这种情况？我准备在一个大的互联网项目里使用smart engine，希望和作者有些沟通。

[vavi]

前几天的代码里，我已经去掉了LockStrategy 的相关代码，并且原来的代码里，默认是空实现。

原来的设计场景，考虑到 fork-join 中的 join 场景，需要分布式锁。

[vavi]

但是有些服务编排场景是需要分布式锁的，还有原来的锁机制实现的颗粒度不合适，无法覆盖特别是 custom 模式下的数据存储环节，所以综上是取消了 LockStrategy 。

但是一般场景下，还是需要业务开发者考虑两种场景：1. 分布式场景下多个请求同时处理一个任务实例 2. 分布式场景下处理 fork-join 场景； 我理解这两种情况下还是需要分布式锁的。 不过1 场景下常规的处理是数库库乐观锁。

[Zhonghua8]

但是有些服务编排场景是需要分布式锁的，还有原来的锁机制实现的颗粒度不合适，无法覆盖特别是 custom 模式下的数据存储环节，所以综上是取消了 LockStrategy 。

但是一般场景下，还是需要业务开发者考虑两种场景：1. 分布式场景下多个请求同时处理一个任务实例 2. 分布式场景下处理 fork-join 场景； 我理解这两种情况下还是需要分布式锁的。 不过1 场景下常规的处理是数库库乐观锁。

我在预发环境监测发现使用SmartEngine编排的服务，除了自己的业务逻辑外，SmartEngine本身耗时在20ms左右，请问你们有没有SmartEngine的耗时情况？有没有什么优化方法可以使耗时更少？

[Zhonghua8]

但是有些服务编排场景是需要分布式锁的，还有原来的锁机制实现的颗粒度不合适，无法覆盖特别是 custom 模式下的数据存储环节，所以综上是取消了 LockStrategy 。

但是一般场景下，还是需要业务开发者考虑两种场景：1. 分布式场景下多个请求同时处理一个任务实例 2. 分布式场景下处理 fork-join 场景； 我理解这两种情况下还是需要分布式锁的。 不过1 场景下常规的处理是数库库乐观锁。

加个联系方式吧，怎么联系你呢，可以更快的咨询或者向你反馈一些问题

[vavi]

其实我的联系方式，README 里就有。。。

[vavi]

但是有些服务编排场景是需要分布式锁的，还有原来的锁机制实现的颗粒度不合适，无法覆盖特别是 custom 模式下的数据存储环节，所以综上是取消了 LockStrategy 。
但是一般场景下，还是需要业务开发者考虑两种场景：1. 分布式场景下多个请求同时处理一个任务实例 2. 分布式场景下处理 fork-join 场景； 我理解这两种情况下还是需要分布式锁的。 不过1 场景下常规的处理是数库库乐观锁。

我在预发环境监测发现使用SmartEngine编排的服务，除了自己的业务逻辑外，SmartEngine本身耗时在20ms左右，请问你们有没有SmartEngine的耗时情况？有没有什么优化方法可以使耗时更少？
=========
20ms ，这个是不可能的。 可能你每次都 deploy 了 xml，解析时间相对可能比较多一些。deploy 方法最好在启动时初始化，或者在必要时重新 deploy。

我以前压测过，一次驱动流程都是在 0.01 ms 以内的。