後端知識
名詞
惊群现象
接口
nginx web 服務器
uwsgi
FastCGI
wsgi
四層架構
需要了解的是，数据传输对象 DTO 本身并不是业务对象。数据传输对象是根据 UI 的需求进行设计的，而不 是根据领域对象进行设计的。比如，Customer 领域对象可能会包含一些诸如 FirstName, LastName, Email, Address 等信息。但如果 UI 上不打算显示 Address 的信息，那么 CustomerDTO 中也无需包含这个 Address 的数据
简单来说 Model 面向业务，我们是通过业务来定义 Model 的。而 DTO 是面向界面 UI，是通过 UI 的需求来定义的。通过 DTO 我们实现了表现层与 Model 之间的解耦，表现层不引用 Model，如果开发过程中我们的模型改变了，而界面没变，我们就只需要改 Model 而不需要去改表现层中的东西。
GIL （Global Interpreter Lock）
全局解釋器鎖
全局排他锁
tcp & unix socket
驗證
Cookie & Session
JSON Web Token（JWT）
Cookie在客端，Session在Server端
timezone-aware
timezone-naive
架構
數據層
介面層（展示層）
邏輯層
充血＆貧血模型
攻擊
生日攻擊
UUID
v1
v2
v3、v5
v4
根據時間和節點 ID（通常是 MAC 位址）
全隨機
UserID or GroupID + v1
v3 = MD5
v5 = SHA1
Benchmarking & Profiling
緩存
LRU(least recently used)
DB
Redis
讀取次數遠高於寫入次數
詢方式單一而簡單，時間複雜度 O (1)(再不用 keys 指令情況下)
雖然有多種數據結構，但終究 只能 由 key 查詢 value
沒有持久化的需求，可以容忍數據丟失，反正丟了再查詢寫入
HBase
Ram Base
列式儲存，橫向擴展能力
支持海量資料讀寫，且擴展方便
經常將 RDB (關聯式資料庫) 的資料依據 pk 取出後存入列中方便查詢
如果沒有明確要查詢 key 值，用 scan 查詢能力非常低下，幾乎查不出來那種
沒有分頁功能，因爲根本統計不了有多少資料
非常依賴 Row key 很吃使用經驗，一個不小心就殺雞用牛刀了
MongoDB
基本就是可以直接把字段或 json 整個塞進去
創建索引後可以視爲爲車廂命名，查找速度會變得優異
二級索引並不會輸關聯式資料庫
多表之間 join 查詢相當麻煩
空間佔用較大，有空間預分配機制，且刪除數據後還需要下指令釋放空間
對於沒有 join 與強制性數據類型的資料存取相當方便
ElasticSearch
good
bad
支援中文分詞，Ex: 今晚想來點星巴克 -> 今晚，想來點，星巴克
強大的全文索引，可以從海量資料中撈出晚上喝星巴克的日子
變態級的聚合操作，類似一般關聯型使用 group By 但功能更加強大
能夠自動發現新的或失敗節點，將資料重組與重新平衡權級，確保數據安全及可訪問
因爲是使用倒排索引然後定期使用 Segment File，因此寫入並非實時 (但大部分情況仍小於 1sec)
非常吃硬體資源數據量大的情況下 64G+SSD 算是標配
- 檢索：爬取內容
- 索引：進行分詞並建立分詞索引
- 排名：依據分詞索引內容建立倒排算出優先級
good
表结构灵活可变，字段类型可以随时修改
MongoDB 很适合那些表结构经常改变，数据的逻辑结构没又没那么复杂不需要多表查询操作，数据量又比较大的应用场景
自动建立索引使得 ES 的写入性能也收到了影响，要明显低于 MongoDB
ES 在数据结构灵活度上高于 MySQL 但远不如 MongoDB
ES 很好的支持了复杂聚合查询这一特点还使得 ES 非常适合拿来作数据分析使用。
SSO (Single Sign On)
dto = api 文件的數據結構對象
supervisor 守護進程
任何時刻僅有一個執行緒在執行
即默认 python 内部对象是 thread-safe 的，无需在实现时考虑额外的内存锁和同步操作
線程 thread / 進程 process
thread
IO Bound
CPU Bound
share memory 難處
thread 可通過 lock 達成
process 只能通過 memory cache
雙機備份（熱備）
CAP 定理
C 一致性
A 可用性
P 分區容錯性
CAP 定理告訴我們，在分散式系統中，這三個特性只能同時滿足兩個
通常只有 CP(敏感) 或 AP(不敏感)
使用者讀到的” 總是” 最新的資料
使用者的請求” 總是” 可以獲得回應，也就是可以正常讀寫 （回傳錯誤訊息並不算滿足可用性）
就算網路出現問題導致資料分區，整個系統仍然要可以繼續運作
強一致性
適合：金額 帳單
最終一致性
適合資料更新可以有一點延遲的場合
文章的新留言、影片總共觀看人數等等
ACID
用於討論分散式架構
用來討論寫入操作
鎖
分布式鎖
Redis setnx
鎖續命
進程鎖
zookeeper
讀寫鎖
消息
點對點
MessageQueue
一個消息只能被一個消費者執行
消息非即時處理，會等待消費
消息不遺失
只能處裡非指向性的消息
（不指定消費者）
訂閱發布
消費者實時處理
可能遺失
一個消息可以多個消費者執行
Channel
不保證送達
保證送達的訂閱發布
在 channel 中使用 list 存放消息，等待消化
集群架構
集群
哨兵
主從
CP
zookeeper
AP
redis
當寫入主結點一筆數據
半數以上同步後才回覆寫入成功
選舉機制
ZAB
concurrent container
分段式鎖
問題
緩存穿透
緩存無底洞
緩存雪崩
緩存失效
熱點key傾斜
熱點key重建
緩存數據庫雙寫不一致
更新完ＤＢ後直接刪緩存
而不是更新緩存
性能必須提升
原子操作
三高架構
高並發
高可用
高性能
一線技術棧
分布式架構
微服務架構
高並發
中間件
分布式消息中間件
分布式儲存中間件
RabbitMQ
RocketMQ
Kafka
Redis
Mongo
FastDFS
ElasticSearch
分布式架構
Zookeeper
Dubbo
ShardingSphere
Netty
限流降級熔斷
寫操作才去鎖讀
讀鎖不鎖讀鎖
適合讀多寫少的場景
LVS
限流策略
多級緩存
流量削峰
令牌桶，漏桶算法
Seninel/Hystrix限流
防刷
降級
後台
服務發現
統一配置
Admin 服務治理
服務註冊
指標
QPS 每秒查詢數
TPS 每秒事務數
HPS 每秒 HTTP 請求數
並發數＝QPS*平均響應時間
RPS 吞吐量
TP{N} 分位值
PV 綜合瀏覽量
UV 獨立訪客
分詞，去重，排序
DSL
query
term 不拆分
match
multi_match
query_string
range
filter
不計算分值，不排序，可緩存，效率高
click to edit
mapping
keyword 不拆分
text 會用分詞器
integer
index, store
概念
索引
表
鎖
事務
零拷貝
連線池
設計模式
Actor
請求排隊
每個 actor 都是無鎖的
發送者 發送異步消息，接收者處理完後根據發送地址送回消息
不用使用鎖去等待回應
異步處理消息
可能 http res/req 或 rpc 更好
(3) 高并发事务解决之道
悲观锁 - 数据库表锁或行锁
乐观锁 - 版本控制
同步锁 - 单线程
Actor 模型 - 行为消息队列（适用跨节点、分布式、高并发）
- 同步锁是单一 JVM 内的，对于分布式系统多个 Tomcat 容器多个 JVM，Actor 模型能更好地 [锁] 好资源。
Reactor
事件註冊
事件發生
事件回調
libevent
skynet
Proacotr
标准 / 典型的 Reactor：
- 步骤 1：等待事件到来（Reactor 负责）
- 步骤 2：将读就绪事件分发给用户定义的处理器（Reactor 负责）
- 步骤 3：读数据（用户处理器负责）
- 步骤 4：处理数据（用户处理器负责）
改进实现的模拟 Proactor：
- 步骤 1：等待事件到来（Proactor 负责）
- 步骤 2：得到读就绪事件，执行读数据（现在由 Proactor 负责）
- 步骤 3：将读完成事件分发给用户处理器（Proactor 负责）
- 步骤 4：处理数据（用户处理器负责）
每個 actor 不互相共享内存
每個 actor 只透過消息構通
每個 actor 一次處理一條數據
如果要同時處理3條數據，需送給3個 actor
EventSource
OLAP 線上分析處理 / OLTP 線上交易處理
OLTP 處理『資料』 查詢的複雜性要小得多，而且查詢量要大得多的任務
CURD
OLAP 處理『資訊』
聚合 Aggregate
CQRS 讀寫分離
Command Query Responsibility Segregation
六边形架构 (端口适配器)
使用 DDD 领域驱动设计或 CQRS 架构就能明显发现这些情况，CQRS 是读写分离，其中写操作是应领域专家要求编写的功能，在这类方向，我们都有必要使用 Actor 模型实现，因为在这个方向上，领域专家的要求都表达为聚合根实体，聚合根就是用 Actor 模型实现最合适不过了。而读方向，比如大数据处理，报表查询，OLTP 等等都是数据喂机器的方式
冪等操作