Please enable JavaScript.
Coggle requires JavaScript to display documents.
後端知識 (名詞 (CAP 定理 (C 一致性 (使用者讀到的” 總是” 最新的資料, 強一致性
適合：金額 帳單), A 可用性…
後端知識
名詞
-
三高架構
高並發
(3) 高并发事务解决之道
悲观锁 - 数据库表锁或行锁
乐观锁 - 版本控制
同步锁 - 单线程
Actor 模型 - 行为消息队列（适用跨节点、分布式、高并发）
- 同步锁是单一 JVM 内的，对于分布式系统多个 Tomcat 容器多个 JVM，Actor 模型能更好地 [锁] 好资源。
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
DB
-
-
-
ElasticSearch
-
-
- 檢索：爬取內容
- 索引：進行分詞並建立分詞索引
- 排名：依據分詞索引內容建立倒排算出優先級
-
-
-
-
-
-
線程 thread / 進程 process
-
-
-
設計模式
Actor
-
-
-
-
-
-
-
-
-
使用 DDD 领域驱动设计或 CQRS 架构就能明显发现这些情况，CQRS 是读写分离，其中写操作是应领域专家要求编写的功能，在这类方向，我们都有必要使用 Actor 模型实现，因为在这个方向上，领域专家的要求都表达为聚合根实体，聚合根就是用 Actor 模型实现最合适不过了。而读方向，比如大数据处理，报表查询，OLTP 等等都是数据喂机器的方式
-
-
标准 / 典型的 Reactor：
- 步骤 1：等待事件到来（Reactor 负责）
- 步骤 2：将读就绪事件分发给用户定义的处理器（Reactor 负责）
- 步骤 3：读数据（用户处理器负责）
- 步骤 4：处理数据（用户处理器负责）
改进实现的模拟 Proactor：
- 步骤 1：等待事件到来（Proactor 负责）
- 步骤 2：得到读就绪事件，执行读数据（现在由 Proactor 负责）
- 步骤 3：将读完成事件分发给用户处理器（Proactor 负责）
- 步骤 4：处理数据（用户处理器负责）
-
-
四層架構
需要了解的是，数据传输对象 DTO 本身并不是业务对象。数据传输对象是根据 UI 的需求进行设计的，而不 是根据领域对象进行设计的。比如，Customer 领域对象可能会包含一些诸如 FirstName, LastName, Email, Address 等信息。但如果 UI 上不打算显示 Address 的信息，那么 CustomerDTO 中也无需包含这个 Address 的数据
简单来说 Model 面向业务，我们是通过业务来定义 Model 的。而 DTO 是面向界面 UI，是通过 UI 的需求来定义的。通过 DTO 我们实现了表现层与 Model 之间的解耦，表现层不引用 Model，如果开发过程中我们的模型改变了，而界面没变，我们就只需要改 Model 而不需要去改表现层中的东西。
-
-
-
-
-
-
-
-
