后端架構師技術圖譜

（Toc generated by simple-php-github-toc ）

數(shù)據(jù)結構

隊列

集合

鏈表逢慌、數(shù)組

字典悠轩、關聯(lián)數(shù)組

棧

樹

二叉樹

每個節(jié)點最多有兩個葉子節(jié)點。

完全二叉樹

  • 《完全二叉樹》
    • 葉節(jié)點只能出現(xiàn)在最下層和次下層牛欢，并且最下面一層的結點都集中在該層最左邊的若干位置的二叉樹骡男。

平衡二叉樹

左右兩個子樹的高度差的絕對值不超過1，并且左右兩個子樹都是一棵平衡二叉樹傍睹。

二叉查找樹（BST）

二叉查找樹（Binary Search Tree）隔盛，也稱有序二叉樹（ordered binary tree）,排序二叉樹（sorted binary tree）。

紅黑樹

B-，B+熊赖，B*樹

MySQL是基于B+樹聚集索引組織表

LSM 樹

LSM（Log-Structured Merge-Trees）和 B+ 樹相比传趾，是犧牲了部分讀的性能來換取寫的性能(通過批量寫入)，實現(xiàn)讀寫之間的泥技。
Hbase浆兰、LevelDB、Tair（Long DB）珊豹、nessDB 采用 LSM 樹的結構簸呈。LSM可以快速建立索引。

  • 《LSM樹 VS B+樹》

    • B+ 樹讀性能好店茶，但由于需要有序結構蜕便，當key比較分散時，磁盤尋道頻繁贩幻，造成寫性能轿腺。
    • LSM 是將一個大樹拆分成N棵小樹两嘴，先寫到內存（無尋道問題，性能高）族壳，在內存中構建一顆有序小樹（有序樹）憔辫，隨著小樹越來越大，內存的小樹會flush到磁盤上仿荆。當讀時贰您，由于不知道數(shù)據(jù)在哪棵小樹上，因此必須遍歷（二分查找）所有的小樹赖歌，但在每顆小樹內部數(shù)據(jù)是有序的枉圃。

  • 《LSM樹（Log-Structured Merge Tree）存儲引擎》

    • 極端的說，基于LSM樹實現(xiàn)的HBase的寫性能比MySQL高了一個數(shù)量級庐冯，讀性能低了一個數(shù)量級孽亲。
    • 優(yōu)化方式：Bloom filter 替代二分查找；compact 小數(shù)位大樹展父，提高查詢性能返劲。
    • Hbase 中，內存中達到一定閾值后栖茉，整體flush到磁盤上篮绿、形成一個文件（B+數(shù)），HDFS不支持update操作吕漂，所以Hbase做整體flush而不是merge update亲配。flush到磁盤上的小樹，定期會合并成一個大樹惶凝。

BitSet

經常用于大規(guī)模數(shù)據(jù)的排重檢查吼虎。

常用算法

排序、查找算法

選擇排序

冒泡排序

插入排序

快速排序

歸并排序

希爾排序

TODO

堆排序

  • 《圖解排序算法(三)之堆排序》
    • 排序過程就是構建最大堆的過程领跛，最大堆：每個結點的值都大于或等于其左右孩子結點的值肺魁，堆頂元素是最大值。

計數(shù)排序

桶排序

基數(shù)排序

按照個位蹦误、十位劫拢、百位、...依次來排强胰。

二分查找

Java 中的排序工具

布隆過濾器

常用于大數(shù)據(jù)的排重牵寺，比如email，url 等恩脂。
核心原理：將每條數(shù)據(jù)通過計算產生一個指紋（一個字節(jié)或多個字節(jié)帽氓，但一定比原始數(shù)據(jù)要少很多）瘫证，其中每一位都是通過隨機計算獲得榨馁，在將指紋映射到一個大的按位存儲的空間中。注意：會有一定的錯誤率陶耍。
優(yōu)點：空間和時間效率都很高玉凯。
缺點：隨著存入的元素數(shù)量增加势腮，誤算率隨之增加。

字符串比較

KMP 算法

KMP：Knuth-Morris-Pratt算法（簡稱KMP）
核心原理是利用一個“部分匹配表”撑蒜，跳過已經匹配過的元素歹啼。

深度優(yōu)先、廣度優(yōu)先

貪心算法

回溯算法

剪枝算法

動態(tài)規(guī)劃

樸素貝葉斯

推薦算法

最小生成樹算法

最短路徑算法

并發(fā)

多線程

線程安全

一致性座菠、事務

事務 ACID 特性

事務的隔離級別

  • 未提交讀：一個事務可以讀取另一個未提交的數(shù)據(jù)狸眼，容易出現(xiàn)臟讀的情況。

  • 讀提交：一個事務等另外一個事務提交之后才可以讀取數(shù)據(jù)浴滴，但會出現(xiàn)不可重復讀的情況（多次讀取的數(shù)據(jù)不一致）拓萌，讀取過程中出現(xiàn)UPDATE操作，會多升略。（大多數(shù)數(shù)據(jù)庫默認級別是RC微王，比如SQL Server屡限，Oracle），讀取的時候不可以修改炕倘。

  • 可重復讀： 同一個事務里確保每次讀取的時候钧大，獲得的是同樣的數(shù)據(jù)，但不保障原始數(shù)據(jù)被其他事務更新（幻讀）罩旋，Mysql InnoDB 就是這個級別啊央。

  • 序列化：所有事物串行處理（犧牲了效率）

  • 《理解事務的4種隔離級別》

  • 數(shù)據(jù)庫事務的四大特性及事務隔離級別

  • 《MySQL的InnoDB的幻讀問題 》

    • 幻讀的例子非常清楚。
    • 通過 SELECT ... FOR UPDATE 解決涨醋。

  • 《一篇文章帶你讀懂MySQL和InnoDB》

    • 圖解臟讀瓜饥、不可重復讀、幻讀問題浴骂。

MVCC

鎖

Java中的鎖和同步類

公平鎖 & 非公平鎖

公平鎖的作用就是嚴格按照線程啟動的順序來執(zhí)行的浙炼，不允許其他線程插隊執(zhí)行的份氧；而非公平鎖是允許插隊的。

  • 《公平鎖與非公平鎖》
    • 默認情況下 ReentrantLock 和 synchronized 都是非公平鎖弯屈。ReentrantLock 可以設置成公平鎖蜗帜。

悲觀鎖

悲觀鎖如果使用不當（鎖的條數(shù)過多），會引起服務大面積等待资厉。推薦優(yōu)先使用樂觀鎖+重試厅缺。

樂觀鎖 & CAS

ABA 問題

由于高并發(fā)秩伞，在CAS下逞带，更新后可能此A非彼A。通過版本號可以解決纱新，類似于上文Mysql 中提到的的樂觀鎖展氓。

CopyOnWrite容器

可以對CopyOnWrite容器進行并發(fā)的讀脸爱，而不需要加鎖遇汞。CopyOnWrite并發(fā)容器用于讀多寫少的并發(fā)場景。比如白名單簿废，黑名單空入，商品類目的訪問和更新場景，不適合需要數(shù)據(jù)強一致性的場景族檬。

RingBuffer

可重入鎖 & 不可重入鎖

  • 《可重入鎖和不可重入鎖》

    • 通過簡單代碼舉例說明可重入鎖和不可重入鎖白对。
    • 可重入鎖指同一個線程可以再次獲得之前已經獲得的鎖。
    • 可重入鎖可以用戶避免死鎖换怖。
    • Java中的可重入鎖：synchronized 和 java.util.concurrent.locks.ReentrantLock

  • 《ReenTrantLock可重入鎖（和synchronized的區(qū)別）總結》

    • synchronized 使用方便甩恼，編譯器來加鎖，是非公平鎖沉颂。
    • ReenTrantLock 使用靈活条摸，鎖的公平性可以定制。
    • 相同加鎖場景下兆览，推薦使用 synchronized屈溉。

互斥鎖 & 共享鎖

互斥鎖：同時只能有一個線程獲得鎖塞关。比如抬探，ReentrantLock 是互斥鎖，ReadWriteLock 中的寫鎖是互斥鎖。
共享鎖：可以有多個線程同時或的鎖小压。比如线梗，Semaphore、CountDownLatch 是共享鎖怠益，ReadWriteLock 中的讀鎖是共享鎖仪搔。

死鎖

操作系統(tǒng)

計算機原理

CPU

多級緩存

典型的 CPU 有三級緩存昌阿，距離核心越近，速度越快恳邀，空間越小懦冰。L1 一般 32k，L2 一般 256k谣沸，L3 一般12M刷钢。內存速度需要200個 CPU 周期，CPU 緩存需要1個CPU周期乳附。

進程

TODO

線程

協(xié)程

  • 《終結python協(xié)程----從yield到actor模型的實現(xiàn)》
    • 線程的調度是由操作系統(tǒng)負責闯捎，協(xié)程調度是程序自行負責
    • 與線程相比，協(xié)程減少了無謂的操作系統(tǒng)切換.
    • 實際上當遇到IO操作時做切換才更有意義许溅，（因為IO操作不用占用CPU）瓤鼻，如果沒遇到IO操作，按照時間片切換.

Linux

設計模式

設計模式的六大原則

  • 《設計模式的六大原則》
    • 開閉原則：對擴展開放,對修改關閉贤重，多使用抽象類和接口茬祷。
    • 里氏代換原則：基類可以被子類替換，使用抽象類繼承,不使用具體類繼承并蝗。
    • 依賴倒轉原則：要依賴于抽象,不要依賴于具體祭犯，針對接口編程,不針對實現(xiàn)編程。
    • 接口隔離原則：使用多個隔離的接口,比使用單個接口好滚停，建立最小的接口沃粗。
    • 迪米特法則：一個軟件實體應當盡可能少地與其他實體發(fā)生相互作用，通過中間類建立聯(lián)系键畴。
    • 合成復用原則：盡量使用合成/聚合,而不是使用繼承最盅。

23種常見設計模式

應用場景

  • 《細數(shù)JDK里的設計模式》

    • 結構型模式：

      • 適配器：用來把一個接口轉化成另一個接口突雪，如 java.util.Arrays#asList()。
      • 橋接模式：這個模式將抽象和抽象操作的實現(xiàn)進行了解耦涡贱，這樣使得抽象和實現(xiàn)可以獨立地變化咏删，如JDBC；
      • 組合模式：使得客戶端看來單個對象和對象的組合是同等的问词。換句話說督函，某個類型的方法同時也接受自身類型作為參數(shù)麸澜，如 Map.putAll睦裳，List.addAll洪鸭、Set.addAll堂鲤。
      • 裝飾者模式：動態(tài)的給一個對象附加額外的功能凹蜈，這也是子類的一種替代方式遇骑，如 java.util.Collections#checkedList|Map|Set|SortedSet|SortedMap撵枢。
      • 享元模式：使用緩存來加速大量小對象的訪問時間捧请，如 valueOf(int)锋喜。
      • 代理模式：代理模式是用一個簡單的對象來代替一個復雜的或者創(chuàng)建耗時的對象些己，如 java.lang.reflect.Proxy

    • 創(chuàng)建模式:

      • 抽象工廠模式：抽象工廠模式提供了一個協(xié)議來生成一系列的相關或者獨立的對象，而不用指定具體對象的類型嘿般，如 java.util.Calendar#getInstance()段标。
      • 建造模式(Builder)：定義了一個新的類來構建另一個類的實例，以簡化復雜對象的創(chuàng)建炉奴，如：java.lang.StringBuilder#append()逼庞。
      • 工廠方法：就是 一個返* 回具體對象的方法，而不是多個瞻赶，如 java.lang.Object#toString()赛糟、java.lang.Class#newInstance()。
      • 原型模式：使得類的實例能夠生成自身的拷貝砸逊、如：java.lang.Object#clone()璧南。
      • 單例模式：全局只有一個實例，如 java.lang.Runtime#getRuntime()师逸。

    • 行為模式：

      • 責任鏈模式：通過把請求從一個對象傳遞到鏈條中下一個對象的方式司倚，直到請求被處理完畢，以實現(xiàn)對象間的解耦篓像。如 javax.servlet.Filter#doFilter()动知。
      • 命令模式：將操作封裝到對象內，以便存儲员辩，傳遞和返回盒粮，如：java.lang.Runnable。
      • 解釋器模式：定義了一個語言的語法奠滑，然后解析相應語法的語句丹皱，如妒穴，java.text.Format，java.text.Normalizer种呐。
      • 迭代器模式：提供一個一致的方法來順序訪問集合中的對象，如 java.util.Iterator弃甥。
      • 中介者模式：通過使用一個中間對象來進行消息分發(fā)以及減少類之間的直接依賴爽室，java.lang.reflect.Method#invoke()。
      • 空對象模式：如 java.util.Collections#emptyList()淆攻。
      • 觀察者模式：它使得一個對象可以靈活的將消息發(fā)送給感興趣的對象阔墩，如 java.util.EventListener。
      • 模板方法模式：讓子類可以重寫方法的一部分瓶珊，而不是整個重寫啸箫，如 java.util.Collections#sort()。

  • 《Spring-涉及到的設計模式匯總》

  • 《Mybatis使用的設計模式》

單例模式

責任鏈模式

TODO

MVC

IOC

  • 《理解 IOC》
  • 《IOC 的理解與解釋》
    • 正向控制：傳統(tǒng)通過new的方式忘苛。反向控制，通過容器注入對象唱较。
    • 作用：用于模塊解耦扎唾。
    • DI：Dependency Injection，即依賴注入南缓，只關心資源使用胸遇，不關心資源來源。

AOP

UML

微服務思想

康威定律

  • 《微服務架構的理論基礎 - 康威定律》

    • 定律一：組織溝通方式會通過系統(tǒng)設計表達出來，就是說架構的布局和組織結構會有相似岔冀。
    • 定律二：時間再多一件事情也不可能做的完美庵楷，但總有時間做完一件事情。一口氣吃不成胖子楣颠，先搞定能搞定的尽纽。
    • 定律三：線型系統(tǒng)和線型組織架構間有潛在的異質同態(tài)特性。種瓜得瓜童漩，做獨立自治的子系統(tǒng)減少溝通成本弄贿。
    • 定律四：大的系統(tǒng)組織總是比小系統(tǒng)更傾向于分解。合久必分矫膨，分而治之差凹。

  • 《微服務架構核?20講》

運維 & 統(tǒng)計 & 技術支持

常規(guī)監(jiān)控

命令行監(jiān)控工具

APM

APM — Application Performance Management

統(tǒng)計分析

持續(xù)集成(CI/CD)

Jenkins

環(huán)境分離

開發(fā)褥傍、測試儡嘶、生成環(huán)境分離。

自動化運維

Ansible

puppet

chef

測試

TDD 理論

  • 《深度解讀 - TDD（測試驅動開發(fā)）》
    • 基于測試用例編碼功能代碼，XP（Extreme Programming）的核心實踐.
    • 好處：一次關注一個點朋贬，降低思維負擔凯楔；迎接需求變化或改善代碼的設計；提前澄清需求锦募；快速反饋摆屯；

單元測試

壓力測試

全鏈路壓測

A/B 、灰度滞项、藍綠測試

虛擬化

KVM

Xen

OpenVZ

容器技術

Docker

云技術

OpenStack

DevOps

文檔管理

中間件

Web Server

Nginx

  • 《Ngnix的基本學習-多進程和Apache的比較》

    • Nginx 通過異步非阻塞的事件處理機制實現(xiàn)高并發(fā)潭流。Apache 每個請求獨占一個線程竞惋，非常消耗系統(tǒng)資源。
    • 事件驅動適合于IO密集型服務(Nginx)灰嫉，多進程或線程適合于CPU密集型服務(Apache)拆宛，所以Nginx適合做反向代理，而非web服務器使用讼撒。

  • 《nginx與Apache的對比以及優(yōu)缺點》

    • nginx只適合靜態(tài)和反向代理浑厚，不適合處理動態(tài)請求。

OpenResty

Apache Httpd

Tomcat

架構原理

調優(yōu)方案

Jetty

  • 《Jetty 的工作原理以及與 Tomcat 的比較》
  • 《jetty和tomcat優(yōu)勢比較》
    • 架構比較:Jetty的架構比Tomcat的更為簡單。
    • 性能比較：Jetty和Tomcat性能方面差異不大担映，Jetty默認采用NIO結束在處理I/O請求上更占優(yōu)勢废士，Tomcat默認采用BIO處理I/O請求，Tomcat適合處理少數(shù)非常繁忙的鏈接蝇完，處理靜態(tài)資源時性能較差官硝。
    • 其他方面：Jetty的應用更加快速，修改簡單短蜕，對新的Servlet規(guī)范的支持較好;Tomcat 對JEE和Servlet 支持更加全面氢架。

緩存

本地緩存

客戶端緩存

服務端緩存

Memcached

Redis

  • 《Redis 教程》

  • 《redis底層原理》

    • 使用 ziplist 存儲鏈表摩梧，ziplist是一種壓縮鏈表物延，它的好處是更能節(jié)省內存空間，因為它所存儲的內容都是在連續(xù)的內存區(qū)域當中的仅父。
    • 使用 skiplist(跳躍表)來存儲有序集合對象叛薯、查找上先從高Level查起、時間復雜度和紅黑樹相當笙纤，實現(xiàn)容易耗溜，無鎖、并發(fā)性好省容。

  • 《Redis持久化方式》

    • RDB方式：定期備份快照抖拴，常用于災難恢復。優(yōu)點：通過fork出的進程進行備份腥椒，不影響主進程阿宅、RDB 在恢復大數(shù)據(jù)集時的速度比 AOF 的恢復速度要快候衍。缺點：會丟數(shù)據(jù)。
    • AOF方式：保存操作日志方式洒放。優(yōu)點：恢復時數(shù)據(jù)丟失少脱柱，缺點：文件大，回復慢拉馋。
    • 也可以兩者結合使用榨为。

  • 《分布式緩存--序列3--原子操作與CAS樂觀鎖》

架構

回收策略

Tair

  • 官方網站
  • 《Tair和Redis的對比》
  • 特點：可以配置備份節(jié)點數(shù)目，通過異步同步到備份節(jié)點
  • 一致性Hash算法煌茴。
  • 架構：和Hadoop 的設計思想類似随闺，有Configserver，DataServer蔓腐，Configserver 通過心跳來檢測矩乐，Configserver也有主備關系。

幾種存儲引擎:

  • MDB回论，完全內存性散罕，可以用來存儲Session等數(shù)據(jù)。
  • Rdb（類似于Redis）傀蓉，輕量化欧漱，去除了aof之類的操作，支持Restfull操作
  • LDB（LevelDB存儲引擎）葬燎，持久化存儲误甚，LDB 作為rdb的持久化，google實現(xiàn)谱净，比較高效窑邦，理論基礎是LSM(Log-Structured-Merge Tree)算法，現(xiàn)在內存中修改數(shù)據(jù)壕探，達到一定量時（和內存匯總的舊數(shù)據(jù)一同寫入磁盤）再寫入磁盤冈钦，存儲更加高效，縣比喻Hash算法李请。
  • Tair采用共享內存來存儲數(shù)據(jù)瞧筛，如果服務掛掉（非服務器），重啟服務之后捻艳，數(shù)據(jù)亦然還在驾窟。

消息隊列

消息總線

消息總線相當于在消息隊列之上做了一層封裝此叠，統(tǒng)一入口，統(tǒng)一管控随珠、簡化接入成本灭袁。

消息的順序

RabbitMQ

支持事務，推拉模式都是支持窗看、適合需要可靠性消息傳輸?shù)膱鼍啊?/p>

RocketMQ

Java實現(xiàn)茸歧，推拉模式都是支持，吞吐量遜于Kafka显沈∪硐梗可以保證消息順序。

ActiveMQ

純Java實現(xiàn)拉讯，兼容JMS涤浇，可以內嵌于Java應用中。

Kafka

高吞吐量魔慷、采用拉模式只锭。適合高IO場景，比如日志同步盖彭。

Redis 消息推送

生產者竟痰、消費者模式完全是客戶端行為戚绕，list 和 拉模式實現(xiàn)绑嘹，阻塞等待采用 blpop 指令戴甩。

ZeroMQ

TODO

定時調度

單機定時調度

分布式定時調度

RPC

Dubbo

** SPI **
TODO

Thrift

gRPC

服務端可以認證加密栅炒，在外網環(huán)境下，可以保證數(shù)據(jù)安全术羔。

數(shù)據(jù)庫中間件

Sharding Jdbc

日志系統(tǒng)

日志搜集

配置中心

servlet 3.0 異步特性可用于配置中心的客戶端

API 網關

主要職責：請求轉發(fā)、安全認證级历、協(xié)議轉換释移、容災。

網絡

協(xié)議

OSI 七層協(xié)議

TCP/IP

HTTP

HTTP2.0

HTTPS

網絡模型

  • 《web優(yōu)化必須了解的原理之I/o的五種模型和web的三種工作模式》

    • 五種I/O模型：阻塞I/O，非阻塞I/O叮盘，I/O復用秩贰、事件(信號)驅動I/O、異步I/O柔吼，前四種I/O屬于同步操作毒费，I/O的第一階段不同、第二階段相同愈魏，最后的一種則屬于異步操作觅玻。
    • 三種 Web Server 工作方式：Prefork(多進程)艇棕、Worker方式(線程方式)、Event方式串塑。

  • 《select沼琉、poll、epoll之間的區(qū)別總結》

    • select桩匪，poll打瘪，epoll本質上都是同步I/O，因為他們都需要在讀寫事件就緒后自己負責進行讀寫傻昙，也就是說這個讀寫過程是阻塞的闺骚。
    • select 有打開文件描述符數(shù)量限制，默認1024（2048 for x64）妆档，100萬并發(fā)僻爽，就要用1000個進程、切換開銷大贾惦；poll采用鏈表結構胸梆，沒有數(shù)量限制。
    • select须板，poll “醒著”的時候要遍歷整個fd集合碰镜，而epoll在“醒著”的時候只要判斷一下就緒鏈表是否為空就行了，通過回調機制節(jié)省大量CPU時間习瑰；select绪颖，poll每次調用都要把fd集合從用戶態(tài)往內核態(tài)拷貝一次，而epoll只要一次拷貝甜奄。
    • poll會隨著并發(fā)增加柠横，性能逐漸下降，epoll采用紅黑樹結構课兄，性能穩(wěn)定牍氛，不會隨著連接數(shù)增加而降低。

  • 《select第喳，poll糜俗，epoll比較 》

    • 在連接數(shù)少并且連接都十分活躍的情況下，select和poll的性能可能比epoll好曲饱，畢竟epoll的通知機制需要很多函數(shù)回調。

  • 《深入理解Java NIO》

    • NIO 是一種同步非阻塞的 IO 模型珠月。同步是指線程不斷輪詢 IO 事件是否就緒扩淀，非阻塞是指線程在等待 IO 的時候，可以同時做其他任務

  • 《BIO與NIO啤挎、AIO的區(qū)別》

  • 《兩種高效的服務器設計模型：Reactor和Proactor模型》

Epoll

Java NIO

kqueue

連接和短連接

框架

零拷貝（Zero-copy）

序列化(二進制協(xié)議)

Hessian

Protobuf

數(shù)據(jù)庫

基礎理論

數(shù)據(jù)庫設計的三大范式

  • 《數(shù)據(jù)庫的三大范式以及五大約束》
    • 第一范式：數(shù)據(jù)表中的每一列（每個字段）必須是不可拆分的最小單元冠绢，也就是確保每一列的原子性抚吠；
    • 第二范式（2NF）：滿足1NF后，要求表中的所有列弟胀，都必須依賴于主鍵楷力，而不能有任何一列與主鍵沒有關系，也就是說一個表只描述一件事情孵户；
    • 第三范式：必須先滿足第二范式（2NF）弥雹，要求：表中的每一列只與主鍵直接相關而不是間接相關，（表中的每一列只能依賴于主鍵）延届；

MySQL

原理

InnoDB

優(yōu)化

索引

聚集索引, 非聚集索引

MyISAM 是非聚集，InnoDB 是聚集

復合索引

自適應哈希索引(AHI)

explain

NoSQL

MongoDB

  • MongoDB 教程
  • 《Mongodb相對于關系型數(shù)據(jù)庫的優(yōu)缺點》
    • 優(yōu)點：弱一致性（最終一致）方庭，更能保證用戶的訪問速度厕吉；內置GridFS，支持大容量的存儲械念；Schema-less 數(shù)據(jù)庫头朱，不用預先定義結構；內置Sharding龄减；相比于其他NoSQL项钮，第三方支持豐富；性能優(yōu)越希停；
    • 缺點：mongodb不支持事務操作烁巫；mongodb占用空間過大；MongoDB沒有如MySQL那樣成熟的維護工具宠能，這對于開發(fā)和IT運營都是個值得注意的地方亚隙；

Hbase

搜索引擎

搜索引擎原理

Lucene

Elasticsearch

Solr

sphinx

性能

性能優(yōu)化方法論

容量評估

CDN 網絡

連接池

性能調優(yōu)

大數(shù)據(jù)

流式計算

Storm

Flink

Kafka Stream

應用場景

例如：

  • 廣告相關實時統(tǒng)計；
  • 推薦系統(tǒng)用戶畫像標簽實時更新术徊；
  • 線上服務健康狀況實時監(jiān)測本刽；
  • 實時榜單糙捺；
  • 實時數(shù)據(jù)統(tǒng)計妇萄。

Hadoop

HDFS

MapReduce

Yarn

Spark

安全

web 安全

XSS

CSRF

SQL 注入

Hash Dos

腳本注入

漏洞掃描工具

驗證碼

DDoS 防范

用戶隱私信息保護

  1. 用戶密碼非明文保存贝奇，加動態(tài)slat虹菲。
  2. 身份證號，手機號如果要顯示掉瞳，用 “*” 替代部分字符毕源。
  3. 聯(lián)系方式在的顯示與否由用戶自己控制。
  4. TODO

序列化漏洞

加密解密

對稱加密

  • 《常見對稱加密算法》
    • DES该镣、3DES冻璃、Blowfish、AES
    • DES 采用 56位秘鑰损合，Blowfish 采用1到448位變長秘鑰省艳，AES 128，192和256位長度的秘鑰嫁审。
    • DES 秘鑰太短（只有56位）算法目前已經被 AES 取代跋炕，并且 AES 有硬件加速，性能很好律适。

哈希算法

非對稱加密

  • 《常見非對稱加密算法》

    • RSA纠修、DSA、ECDSA(螺旋曲線加密算法)

    • 和 RSA 不同的是 DSA 僅能用于數(shù)字簽名厂僧，不能進行數(shù)據(jù)加密解密扣草，其安全性和RSA相當，但其性能要比RSA快颜屠。

    • 256位的ECC秘鑰的安全性等同于3072位的RSA秘鑰辰妙。

      《區(qū)塊鏈的加密技術》

服務器安全

數(shù)據(jù)安全

數(shù)據(jù)備份

TODO

網絡隔離

內外網分離

TODO

登錄跳板機

在內外環(huán)境中通過跳板機登錄到線上主機。

授權汽纤、認證

RBAC

OAuth2.0

雙因素認證（2FA）

2FA - Two-factor authentication上岗，用于加強登錄驗證

常用做法是 登錄密碼 + 手機驗證碼（或者令牌Key，類似于與網銀的 USB key）

單點登錄(SSO)

常用開源框架

開源協(xié)議

日志框架

Log4j蕴坪、Log4j2

Logback

ORM

MyBatis：

  • 《mybatis緩存機制詳解》

    • 一級緩存是SqlSession級別的緩存呆瞻，緩存的數(shù)據(jù)只在SqlSession內有效
    • 二級緩存是mapper級別的緩存，同一個namespace公用這一個緩存径玖，所以對SqlSession是共享的痴脾；使用 LRU 機制清理緩存，通過 cacheEnabled 參數(shù)開啟梳星。

  • 《MyBatis學習之代碼生成器Generator》

網絡框架

TODO

Web 框架

Spring 家族

Spring

Spring Boot

Spring Cloud

工具框架

分布式設計

擴展性設計

穩(wěn)定性 & 高可用

  • 《系統(tǒng)設計：關于高可用系統(tǒng)的一些技術方案》
    • 可擴展：水平擴展、垂直擴展椿疗。 通過冗余部署漏峰，避免單點故障。
    • 隔離：避免單一業(yè)務占用全部資源届榄。避免業(yè)務之間的相互影響 2. 機房隔離避免單點故障浅乔。
    • 解耦：降低維護成本，降低耦合風險痒蓬。減少依賴童擎，減少相互間的影響。
    • 限流：滑動窗口計數(shù)法攻晒、漏桶算法顾复、令牌桶算法等算法。遇到突發(fā)流量時鲁捏，保證系統(tǒng)穩(wěn)定芯砸。
    • 降級：緊急情況下釋放非核心功能的資源。犧牲非核心業(yè)務给梅，保證核心業(yè)務的高可用假丧。
    • 熔斷：異常情況超出閾值進入熔斷狀態(tài)，快速失敗动羽。減少不穩(wěn)定的外部依賴對核心服務的影響包帚。
    • 自動化測試：通過完善的測試，減少發(fā)布引起的故障运吓。
    • 灰度發(fā)布：灰度發(fā)布是速度與安全性作為妥協(xié)渴邦，能夠有效減少發(fā)布故障。
  • 《關于高可用的系統(tǒng)》
    • 設計原則：數(shù)據(jù)不丟(持久化)拘哨；服務高可用(服務副本)谋梭；絕對的100%高可用很難，目標是做到盡可能多的9倦青，如99.999%（全年累計只有5分鐘）瓮床。

硬件負載均衡

軟件負載均衡

限流

  • 《談談高并發(fā)系統(tǒng)的限流》
    • 計數(shù)器：通過滑動窗口計數(shù)器织阳，控制單位時間內的請求次數(shù)，簡單粗暴砰粹。
    • 漏桶算法：固定容量的漏桶唧躲，漏桶滿了就丟棄請求，比較常用碱璃。
    • 令牌桶算法：固定容量的令牌桶弄痹，按照一定速率添加令牌，處理請求前需要拿到令牌嵌器，拿不到令牌則丟棄請求肛真，或進入丟隊列，可以通過控制添加令牌的速率爽航，來控制整體速度蚓让。Guava 中的 RateLimiter 是令牌桶的實現(xiàn)。
    • Nginx 限流：通過 limit_req 等模塊限制并發(fā)連接數(shù)岳掐。

應用層容災

  • 《防雪崩利器：熔斷器 Hystrix 的原理與使用》

    • 雪崩效應原因：硬件故障凭疮、硬件故障、程序Bug串述、重試加大流量执解、用戶大量請求。
    • 雪崩的對策：限流、改進緩存模式(緩存預加載衰腌、同步調用改異步)新蟆、自動擴容、降級右蕊。
    • Hystrix設計原則：
      • 資源隔離：Hystrix通過將每個依賴服務分配獨立的線程池進行資源隔離, 從而避免服務雪崩琼稻。
      • 熔斷開關：服務的健康狀況 = 請求失敗數(shù) / 請求總數(shù)，通過閾值設定和滑動窗口控制開關饶囚。
      • 命令模式：通過繼承 HystrixCommand 來包裝服務調用邏輯帕翻。

  • 《緩存穿透，緩存擊穿萝风，緩存雪崩解決方案分析》

  • 《緩存擊穿嘀掸、失效以及熱點key問題》

    • 主要策略：失效瞬間：單機使用鎖；使用分布式鎖规惰；不過期睬塌；
    • 熱點數(shù)據(jù)：熱點數(shù)據(jù)單獨存儲；使用本地緩存歇万；分成多個子key揩晴；

跨機房容災

  • 《“異地多活”多機房部署經驗談》

    • 通過自研中間件進行數(shù)據(jù)同步。

  • 《異地多活（異地雙活）實踐經驗》

    • 注意延遲問題贪磺，多次跨機房調用會將延時放大數(shù)倍硫兰。
    • 建房間專線很大概率會出現(xiàn)問題，做好運維和程序層面的容錯缘挽。
    • 不能依賴于程序端數(shù)據(jù)雙寫瞄崇，要有自動同步方案。
    • 數(shù)據(jù)永不在高延遲和較差網絡質量下壕曼，考慮同步質量問題苏研。
    • 核心業(yè)務和次要業(yè)務分而治之，甚至只考慮核心業(yè)務。
    • 異地多活監(jiān)控部署、測試也要跟上舀透。
    • 業(yè)務允許的情況下考慮用戶分區(qū)，尤其是游戲衅鹿、郵箱業(yè)務。
    • 控制跨機房消息體大小过咬，越小越好大渤。
    • 考慮使用docker容器虛擬化技術，提高動態(tài)調度能力掸绞。

  • 容災技術及建設經驗介紹

容災演練流程

平滑啟動

數(shù)據(jù)庫擴展

讀寫分離模式

分片模式

  • 《分庫分表需要考慮的問題及方案》

    • 中間件： 輕量級：sharding-jdbc、TSharding抚垄；重量級：Atlas蜕窿、MyCAT、Vitess等呆馁。
    • 問題：事務桐经、Join、遷移浙滤、擴容阴挣、ID、分頁等纺腊。
    • 事務補償：對數(shù)據(jù)進行對帳檢查;基于日志進行比對;定期同標準數(shù)據(jù)來源進行同步等畔咧。
    • 分庫策略：數(shù)值范圍；取模揖膜；日期等誓沸。
    • 分庫數(shù)量：通常 MySQL 單庫 5千萬條、Oracle 單庫一億條需要分庫壹粟。

  • 《MySql分表和表分區(qū)詳解》

    • 分區(qū)：是MySQL內部機制拜隧，對客戶端透明，數(shù)據(jù)存儲在不同文件中，表面上看是同一個表虹蓄。
    • 分表：物理上創(chuàng)建不同的表犀呼、客戶端需要管理分表路由。

服務治理

服務注冊與發(fā)現(xiàn)

服務路由控制

  • 《分布式服務框架學習筆記4 服務路由》
    • 原則：透明化路由
    • 負載均衡策略：隨機掰曾、輪詢、服務調用延遲停团、一致性哈希旷坦、粘滯連接
    • 本地路由有限策略：injvm(優(yōu)先調用jvm內部的服務)，innative(優(yōu)先使用相同物理機的服務),原則上找距離最近的服務佑稠。
    • 配置方式：統(tǒng)一注冊表秒梅；本地配置；動態(tài)下發(fā)讶坯。

分布式一致

CAP 與 BASE 理論

  • 《從分布式一致性談到CAP理論番电、BASE理論》
    • 一致性分類：強一致(立即一致)；弱一致(可在單位時間內實現(xiàn)一致辆琅，比如秒級)漱办；最終一致(弱一致的一種，一定時間內最終一致)
    • CAP：一致性婉烟、可用性娩井、分區(qū)容錯性(網絡故障引起)
    • BASE：Basically Available（基本可用）、Soft state（軟狀態(tài)）和Eventually consistent（最終一致性）
    • BASE理論的核心思想是：即使無法做到強一致性似袁，但每個應用都可以根據(jù)自身業(yè)務特點洞辣，采用適當?shù)姆绞絹硎瓜到y(tǒng)達到最終一致性咐刨。

分布式鎖

  • 《分布式鎖的幾種實現(xiàn)方式》

    • 基于數(shù)據(jù)庫的分布式鎖：優(yōu)點：操作簡單、容易理解扬霜。缺點：存在單點問題定鸟、數(shù)據(jù)庫性能夠開銷較大、不可重入著瓶；
    • 基于緩存的分布式鎖：優(yōu)點：非阻塞联予、性能好。缺點：操作不好容易造成鎖無法釋放的情況材原。
    • Zookeeper 分布式鎖：通過有序臨時節(jié)點實現(xiàn)鎖機制沸久，自己對應的節(jié)點需要最小，則被認為是獲得了鎖余蟹。優(yōu)點：集群可以透明解決單點問題卷胯，避免鎖不被釋放問題，同時鎖可以重入威酒。缺點：性能不如緩存方式窑睁，吞吐量會隨著zk集群規(guī)模變大而下降。

  • 《基于Zookeeper的分布式鎖》

    • 清楚的原理描述 + Java 代碼示例兼搏。

  • 《jedisLock—redis分布式鎖實現(xiàn)》

    • 基于 setnx(set if ont exists)卵慰，有則返回false，否則返回true佛呻。并支持過期時間。

  • 《Memcached 和 Redis 分布式鎖方案》

    • 利用 memcached 的 add（有別于set）操作病线，當key存在時吓著，返回false。

分布式一致性算法

PAXOS

Zab

Raft

Gossip

兩階段提交纺裁、多階段提交

冪等

  • 《分布式系統(tǒng)---冪等性設計》
    • 冪等特性的作用：該資源具備冪等性欺缘，請求方無需擔心重復調用會產生錯誤。
    • 常見保證冪等的手段：MVCC（類似于樂觀鎖）挤安、去重表(唯一索引)谚殊、悲觀鎖、一次性token蛤铜、序列號方式嫩絮。

分布式一致方案

分布式 Leader 節(jié)點選舉

TCC(Try/Confirm/Cancel) 柔性事務

  • 《傳統(tǒng)事務與柔性事務》
    • 基于BASE理論：基本可用丛肢、柔性狀態(tài)、最終一致剿干。
    • 解決方案：記錄日志+補償（正向補充或者回滾）蜂怎、消息重試(要求程序要冪等)；“無鎖設計”置尔、采用樂觀鎖機制杠步。

分布式文件系統(tǒng)

唯一ID 生成

全局唯一ID

  • 《高并發(fā)分布式系統(tǒng)中生成全局唯一Id匯總》

    • Twitter 方案（Snowflake 算法）：41位時間戳+10位機器標識（比如IP设褐，服務器名稱等）+12位序列號(本地計數(shù)器)
    • Flicker 方案：MySQL自增ID + "REPLACE INTO XXX:SELECT LAST_INSERT_ID();"
    • UUID：缺點颠蕴，無序，字符串過長助析，占用空間犀被，影響檢索性能。
    • MongoDB 方案：利用 ObjectId外冀。缺點：不能自增寡键。

  • 《TDDL 在分布式下的SEQUENCE原理》

    • 在數(shù)據(jù)庫中創(chuàng)建 sequence 表，用于記錄雪隧，當前已被占用的id最大值西轩。
    • 每臺客戶端主機取一個id區(qū)間（比如 1000~2000）緩存在本地，并更新 sequence 表中的id最大值記錄脑沿。
    • 客戶端主機之間取不同的id區(qū)間藕畔，用完再取，使用樂觀鎖機制控制并發(fā)庄拇。

一致性Hash算法

設計思想 & 開發(fā)模式

DDD(Domain-driven Design - 領域驅動設計)

  • 《淺談我對DDD領域驅動設計的理解》

    • 概念：DDD 主要對傳統(tǒng)軟件開發(fā)流程(分析-設計-編碼)中各階段的割裂問題而提出注服，避免由于一開始分析不明或在軟件開發(fā)過程中的信息流轉不一致而造成軟件無法交付（和需求方設想不一致）的問題。DDD 強調一切以領域（Domain）為中心措近，強調領域專家（Domain Expert）的作用溶弟，強調先定義好領域模型之后在進行開發(fā)，并且領域模型可以指導開發(fā)（所謂的驅動）熄诡。
    • 過程：理解領域可很、拆分領域、細化領域凰浮，模型的準確性取決于模型的理解深度我抠。
    • 設計：DDD 中提出了建模工具实撒，比如聚合怪瓶、實體、值對象、工廠僵井、倉儲维费、領域服務蝶缀、領域事件來幫助領域建模扩借。

  • 《領域驅動設計的基礎知識總結》

    • 領域（Doamin）本質上就是問題域，比如一個電商系統(tǒng)贱鄙，一個論壇系統(tǒng)等劝贸。
    • 界限上下文（Bounded Context）：闡述子域之間的關系，可以簡單理解成一個子系統(tǒng)或組件模塊逗宁。
    • 領域模型（Domain Model）：DDD的核心是建立（用通用描述語言映九、工具—領域通用語言）正確的領域模型；反應業(yè)務需求的本質瞎颗，包括實體和過程件甥；其貫穿軟件分析、設計哼拔、開發(fā) 的整個過程引有；常用表達領域模型的方式：圖、代碼或文字倦逐；
    • 領域通用語言：領域專家譬正、開發(fā)設計人員都能立即的語言或工具。
    • 經典分層架構：用戶界面/展示層檬姥、應用層导帝、領域層、基礎設施層穿铆，是四層架構模式。
    • 使用的模式：
      • 關聯(lián)盡量少斋荞，盡量單項荞雏，盡量降低整體復雜度。
      • 實體（Entity）：領域中的唯一標示平酿，一個實體的屬性盡量少凤优，少則清晰。
      • 值對象（Value Object）：沒有唯一標識蜈彼，且屬性值不可變筑辨，小二簡單的對象，比如Date幸逆。
      • 領域服務（Domain Service）： 協(xié)調多個領域對象棍辕，只有方法沒有狀態(tài)(不存數(shù)據(jù))暮现；可以分為應用層服務，領域層服務楚昭、基礎層服務栖袋。
      • 聚合及聚合根（Aggregate，Aggregate Root）：聚合定義了一組具有內聚關系的相關對象的集合抚太；聚合根是對聚合引用的唯一元素塘幅；當修改一個聚合時，必須在事務級別尿贫；大部分領域模型中电媳，有70%的聚合通常只有一個實體，30%只有2~3個實體庆亡；如果一個聚合只有一個實體匾乓，那么這個實體就是聚合根；如果有多個實體身冀，那么我們可以思考聚合內哪個對象有獨立存在的意義并且可以和外部直接進行交互钝尸；
      • 工廠（Factory）：類似于設計模式中的工廠模式。
      • 倉儲（Repository）：持久化到DB搂根，管理對象珍促，且只對聚合設計倉儲。

  • 《領域驅動設計(DDD)實現(xiàn)之路》

    • 聚合：比如一輛汽車（Car）包含了引擎（Engine）剩愧、車輪（Wheel）和油箱（Tank）等組件猪叙，缺一不可。

  • 《領域驅動設計系列（2）淺析VO仁卷、DTO穴翩、DO、PO的概念锦积、區(qū)別和用處》

命令查詢職責分離(CQRS)

CQRS — Command Query Responsibility Seperation

貧血橙垢，充血模型

  • 《貧血垛叨，充血模型的解釋以及一些經驗》
    • 失血模型：老子和兒子分別定義，相互不知道柜某，二者實體定義中完全沒有業(yè)務邏輯嗽元，通過外部Service進行關聯(lián)敛纲。
    • 貧血模型：老子知道兒子，兒子也知道老子还棱；部分業(yè)務邏輯放到實體中载慈；優(yōu)點：各層單項依賴，結構清楚珍手，易于維護办铡；缺點：不符合OO思想，相比于充血模式琳要，Service層較為厚重寡具；
    • 充血模型：和貧血模型類似，區(qū)別在于如何劃分業(yè)務邏輯稚补。優(yōu)點：Service層比較薄童叠，只充當Facade的角色，不和DAO打交道课幕、復合OO思想厦坛；缺點：非單項依賴，DO和DAO之間雙向依賴乍惊、和Service層的邏輯劃分容易造成混亂杜秸。
    • 腫脹模式：是一種極端情況，取消Service層润绎、全部業(yè)務邏輯放在DO中撬碟；優(yōu)點：符合OO思想、簡化了分層莉撇；缺點：暴露信息過多呢蛤、很多非DO邏輯也會強行并入DO。這種模式應該避免棍郎。
    • 作者主張使用貧血模式其障。

Actor 模式

TODO

響應式編程

Reactor

TODO

RxJava

TODO

Vert.x

TODO

DODAF2.0

Serverless

TODO

Service Mesh

TODO

項目管理

架構評審

重構

代碼規(guī)范

TODO

代碼 Review

制度還是制度!
另外涂佃，每個公司需要根據(jù)自己的需求和目標制定自己的 check list

RUP

看板管理

SCRUM

SCRUM - 爭球

  • 3個角色:Product Owner(PO) 產品負責人;Scrum Master（SM），推動Scrum執(zhí)行;Team 開發(fā)團隊扶认。
  • 3個工件：Product Backlog 產品TODOLIST侨拦，含優(yōu)先級;Sprint Backlog 功能開發(fā) TODO LIST；燃盡圖辐宾；
  • 五個價值觀：專注狱从、勇氣膨蛮、公開、承諾季研、尊重敞葛。

敏捷開發(fā)

TODO

極限編程（XP）

XP - eXtreme Programming

  • 《主流敏捷開發(fā)方法：極限編程XP》

    • 是一種指導開發(fā)人員的方法論与涡。

    • 4大價值：

      • 溝通：鼓勵口頭溝通惹谐，提高效率。
      • 簡單：夠用就好驼卖。
      • 反饋：及時反饋氨肌、通知相關人。
      • 勇氣：提倡擁抱變化酌畜，敢于重構怎囚。

    • 5個原則：快速反饋、簡單性假設桥胞、逐步修改恳守、提倡更改（小步快跑）、優(yōu)質工作（保證質量的前提下保證小步快跑）贩虾。

    • 5個工作：階段性沖刺催烘；沖刺計劃會議；每日站立會議整胃；沖刺后review颗圣；回顧會議。

結對編程

邊寫碼屁使，邊review在岂。能夠增強代碼質量、減少bug蛮寂。

FMEA管理模式

TODO

通用業(yè)務術語

TODO

技術趨勢

TODO

政策蔽午、法規(guī)

TODO

法律

嚴格遵守刑法253法條

我國刑法第253條之一規(guī)定：

  • 國家機關或者金融、電信酬蹋、交通及老、教育、醫(yī)療等單位的工作人員范抓，違反國家規(guī)定骄恶，將本單位在履行職責或者提供服務過程中獲得的公民個人信息，出售或者非法提供給他人匕垫，情節(jié)嚴重的僧鲁，處3年以下有期徒刑或者拘役，并處或者單處罰金。
  • 竊取或者以其他方法非法獲取上述信息寞秃，情節(jié)嚴重的斟叼，依照前款的規(guī)定處罰。
  • 單位犯前兩款罪的春寿，對單位判處罰金朗涩，并對其直接負責的主管人員和其他直接責任人員，依照各該款的規(guī)定處罰绑改。

最高人民法院谢床、最高人民檢察院關于執(zhí)行《中華人民共和國刑法》確定罪名的補充規(guī)定（四）規(guī)定：觸犯刑法第253條之一第1款之規(guī)定，構成“出售绢淀、非法提供公民個人信息罪”萤悴；觸犯刑法第253條之一第2款之規(guī)定，構成“非法獲取公民個人信息罪”

架構師素質

  • 《架構師畫像》

    • 業(yè)務理解和抽象能力
    • NB的代碼能力
    • 全面：1. 在面對業(yè)務問題上皆的，架構師腦海里是否會浮現(xiàn)出多種技術方案庶艾；2. 在做系統(tǒng)設計時是否考慮到了足夠多的方方面面囚巴；3. 在做系統(tǒng)設計時是否考慮到了足夠多的方方面面漆魔；
    • 全局：是否考慮到了對上下游的系統(tǒng)的影響部宿。
    • 權衡：權衡投入產出比；優(yōu)先級和節(jié)奏控制楞抡；

  • 《關于架構優(yōu)化和設計伟众，架構師必須知道的事情》

    • 要去考慮的細節(jié)：模塊化、輕耦合召廷、無共享架構凳厢；減少各個組件之前的依懶、注意服務之間依懶所有造成的鏈式失敗及影響等竞慢。
    • 基礎設施先紫、配置、測試筹煮、開發(fā)遮精、運維綜合考慮。
    • 考慮人败潦、團隊本冲、和組織的影響。

  • 《如何才能真正的提高自己劫扒，成為一名出色的架構師檬洞？》

  • 《架構師的必備素質和成長途徑》

    • 素質：業(yè)務理解、技術廣度沟饥、技術深度疮胖、豐富經驗环戈、溝通能力、動手能力澎灸、美學素養(yǎng)。
    • 成長路徑：2年積累知識遮晚、4年積累技能和組內影響力性昭、7年積累部門內影響力、7年以上積累跨部門影響力县遣。

  • 《架構設計師—你在哪層樓糜颠？》

    • 第一層的架構師看到的只是產品本身
    • 第二層的架構師不僅看到自己的產品，還看到了整體的方案
    • 第三層的架構師看到的是商業(yè)價值

團隊管理

TODO

招聘

資訊

行業(yè)資訊

公眾號列表

TODO

博客

團隊博客

個人博客

綜合門戶萧求、社區(qū)

國內：

國外：

問答耗帕、討論類社區(qū)

行業(yè)數(shù)據(jù)分析

專項網站

其他類

推薦參考書

在線電子書

紙質書

開發(fā)方面

架構方面

技術管理方面

基礎理論

工具方面

TODO

大數(shù)據(jù)方面

技術資源

開源資源

手冊仿便、文檔体啰、教程

國內：

  • W3Cschool

  • Runoob.com

    • HTML 、 CSS嗽仪、XML荒勇、Java、Python钦幔、PHP枕屉、設計模式等入門手冊。

  • Love2.io

    • 很多很多中文在線電子書鲤氢，是一個全新的開源技術文檔分享平臺搀擂。

  • gitbook.cn

    • 付費電子書。

  • ApacheCN

    • AI卷玉、大數(shù)據(jù)方面系列中文文檔哨颂。

國外：

在線課堂

會議箫措、活動

活動發(fā)布平臺:

常用APP

找工作

工具

代碼托管

文件服務

  • 七牛
  • 又拍云

綜合云服務商

VPS

?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市斤蔓，隨后出現(xiàn)的幾起案子植酥，更是在濱河造成了極大的恐慌，老刑警劉巖弦牡，帶你破解...
    沈念sama閱讀 218,682評論 6贊 507
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件友驮，死亡現(xiàn)場離奇詭異，居然都是意外死亡驾锰，警方通過查閱死者的電腦和手機卸留，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,277評論 3贊 395
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來椭豫，“玉大人耻瑟，你說我怎么就攤上這事∧砻酰” “怎么了匆赃？”我有些...
    開封第一講書人閱讀 165,083評論 0贊 355
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長今缚。 經常有香客問我算柳，道長，這世上最難降的妖魔是什么姓言？ 我笑而不...
    開封第一講書人閱讀 58,763評論 1贊 295
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任瞬项，我火速辦了婚禮，結果婚禮上何荚，老公的妹妹穿的比我還像新娘囱淋。我一直安慰自己，他們只是感情好餐塘，可當我...
    茶點故事閱讀 67,785評論 6贊 392
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布妥衣。 她就那樣靜靜地躺著，像睡著了一般戒傻。 火紅的嫁衣襯著肌膚如雪税手。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 51,624評論 1贊 305
  • 城市分裂傳說
    那天需纳，我揣著相機與錄音芦倒，去河邊找鬼。 笑死不翩，一個胖子當著我的面吹牛兵扬，可吹牛的內容都是我干的麻裳。 我是一名探鬼主播，決...
    沈念sama閱讀 40,358評論 3贊 418
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼器钟，長吁一口氣：“原來是場噩夢啊……” “哼津坑！你這毒婦竟也來了？” 一聲冷哼從身側響起傲霸，我...
    開封第一講書人閱讀 39,261評論 0贊 276
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤国瓮，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后狞谱，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經...
    沈念sama閱讀 45,722評論 1贊 315
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡禁漓，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,900評論 3贊 336
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年跟衅，在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片播歼。...
    茶點故事閱讀 40,030評論 1贊 350
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡伶跷，死狀恐怖，靈堂內的尸體忽然破棺而出秘狞，到底是詐尸還是另有隱情叭莫，我是刑警寧澤，帶...
    沈念sama閱讀 35,737評論 5贊 346
  • ?日本核電站爆炸內幕
    正文 年R本政府宣布烁试，位于F島的核電站雇初，受9級特大地震影響，放射性物質發(fā)生泄漏减响。R本人自食惡果不足惜靖诗，卻給世界環(huán)境...
    茶點故事閱讀 41,360評論 3贊 330
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望支示。 院中可真熱鬧刊橘，春花似錦、人聲如沸颂鸿。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,941評論 0贊 22
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽嘴纺。三九已至败晴，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間颖医，已是汗流浹背位衩。 一陣腳步聲響...
    開封第一講書人閱讀 33,057評論 1贊 270
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留熔萧，地道東北人糖驴。 一個月前我還...
    沈念sama閱讀 48,237評論 3贊 371
  • 代替公主和親
    正文 我出身青樓僚祷，卻偏偏與公主長得像，于是被迫代替她去往敵國和親贮缕。 傳聞我的和親對象是個殘疾皇子辙谜，可洞房花燭夜當晚...
    茶點故事閱讀 44,976評論 2贊 355

推薦閱讀更多精彩內容

  • 后端架構師技術圖譜 最后更新于20180502 數(shù)據(jù)結構隊列集合鏈表、數(shù)組字典感昼、關聯(lián)數(shù)組棧樹二叉樹完全二叉樹平衡二...
    01_小小魚_01閱讀 1,816評論 0贊 38
  • 因為今天是中秋節(jié)装哆，雖然已經很晚了，突發(fā)奇想想看看月亮定嗓，拉開窗簾蜕琴，外面卻是一片漆黑，沒有月亮宵溅，連遠處的路燈都是昏暗...
    易語少女閱讀 141評論 0贊 0
  • 寫在前面 獲得百倍收益的關鍵并非百倍的努力凌简，每個時代的高手都在利用社會和科技的底層邏輯撬動自己，實現(xiàn)跨越式的成長恃逻。...
    范閑閱讀 229評論 3贊 2
  • 你的突然到訪雏搂，我有點不知所措 你的眼神在四下里急切地探尋你內心的空格 你說幾句城里方言，打幾個問號 我用一柄鋤頭一...
    鄉(xiāng)村詩人閱讀 343評論 4贊 9
  • 我從青春的呻吟里逃逸寇损，看見泛黃的扉頁凸郑，打翻了承載希冀的燈盞。哦矛市，那朱雀化身的城門芙沥，搖曳著美艷的身姿，傾倒了一城青春...
    之子于是閱讀 235評論 0贊 0