作者回复: 这位同学你好。热点事件的处理取决于系统实现方式。如果是用数据库或者Redis,就会出现常见的高负载情况下的常见问题,比如加锁会影响速度,不加锁会影响正确性。 在最基本的事件溯源架构下,系统是单线程运行,因此没有多线程/多进程访问的问题。另外状态也都在内存中,状态和计算可以同时恢复,永远一致。你可以想象为事件溯源是将计算逻辑放在了Redis内部。因此事件溯源在高负载环境下有一定的架构优势。
作者回复: 这位同学你好。很不幸的是,在现实情况下很难做到整体架构的事件溯源。 事件溯源有两个假设,一个是所有命令之间存在线性关系,另一个是不具有随机性。但是复杂系统一般存在回路,这样消息之间就不再是线性关系。同时复杂系统一般会用到时钟,一旦业务跟时钟有关,那么很有可能具有随机性,因为时钟是不准确的。 所以,复杂系统不太可能实现整体的事件溯源。 简单的系统一般是线性的,这时候有可能将几个事件溯源的组件拼装成一个更大的事件溯源组件。 是否采用事件溯源设计取决于你觉得组件的正确性有多重要。如果一个组件重要到你需要了解它过去一步一步都发生了什么,那么就可以考虑。
作者回复: 燕羽阳你好。我会在后面第13节课详细讲解怎么在多个实例的情况下解决正确性的问题。
编辑回复: webmin同学,给你的学习热情点赞。07的思考题参考答案,你可以在答疑集锦(二)找到,希望对你有启发!
作者回复: tt你好。事件不会触发事件,而是触发命令。命令会再生成新的事件。命令可以有随机性,但是事件的执行一定不能有随机性。
编辑回复: 给你的学习热情点赞。这节课思考题的答案,你可以在答疑集锦(二)找到,希望对你有启发!