後端知識

名詞

惊群现象

接口

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 而不需要去改表现层中的东西。

test

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 算是標配

  1. 檢索:爬取內容
  2. 索引:進行分詞並建立分詞索引
  3. 排名:依據分詞索引內容建立倒排算出優先級

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重建

緩存數據庫雙寫不一致

更新完DB後直接刪緩存
而不是更新緩存

性能必須提升

原子操作

三高架構

高並發

高可用

高性能

一線技術棧

分布式架構

微服務架構

高並發

中間件

分布式消息中間件

分布式儲存中間件

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

六边形架构 (端口适配器)

test

使用 DDD 领域驱动设计或 CQRS 架构就能明显发现这些情况,CQRS 是读写分离,其中写操作是应领域专家要求编写的功能,在这类方向,我们都有必要使用 Actor 模型实现,因为在这个方向上,领域专家的要求都表达为聚合根实体,聚合根就是用 Actor 模型实现最合适不过了。而读方向,比如大数据处理,报表查询,OLTP 等等都是数据喂机器的方式

冪等操作