本來這次要寫支付相關的話題，主要是這周是我分享，所以就來說說我上一家公司做的事吧
上一家公司同盾，做的一件事就是風控。哪有風險，哪就有風控。風控是app的一道防火牆。
之前所在的部門是企業組，主要是將風控產品輸出給銀行、互金平臺等。這是一塊大蛋糕，有很多的競爭對手。風控需要的是精準和快速，所以我們需要比別人更快，比別人更準。快、準、狠秒殺對手。
我主要的工作就是風控軟件的性能調優，以下是我性能調優分享,不過不是具體怎麼調優，而是調優的思路
什麼是性能?（who）
性能調優，那麼什麼是性能？這裏要講的不是汽車發動機的性能，而是軟件的性能。軟件其實是看不見摸不着的，不同人對軟件的理解也不一樣，所以在不同人眼裏，性能表現的形式就不一樣
作爲架構師（我的目標），在設計軟件的架構的時候，就需要考慮到不同人眼裏的問題----一切盡在掌握之中
什麼是性能調優？（what）
我們知道軟件是放在服務器上跑的，服務器又可分解爲硬件和操作系統。
如上圖，簡單來說包括三塊：硬件、操作系統、應用程序。其實，性能調優就是調節這些內容，包括硬件、操作系統、應用程序。
- 硬件
CPU、內存、磁盤、網卡、其它……， - 操作系統
進程、虛擬內存、文件系統、網絡、其它……， - 應用程序
常見的有Apache、MySQL、Nginx、Memcahed等。
性能調優就是對計算機硬件、操作系統和應用有相當深入的瞭解，調節三者之間的關係，實現整個系統(包括硬件、操作系統、應用)的性能最大化。
爲什麼需要性能調優？（why）
場景一：當用戶量達到一定數量時，應用就非常非常的慢。這時問老闆能不能加機器。老闆說，其他公司的服務也就一臺服務器，別人行，我們爲什麼不行。坑我錢呢？（嘻嘻😁）
場景二：同樣的需求，100個人實現，有100種不同的寫法。有秒級的，有100毫秒級，有10毫秒級的，有1毫秒級的。這就是菜鳥與高手的區別。通過性能調優，能讓我們瞭解底層的實現。
一、爲了獲得更好的系統性能(就是你現有的系統運行的還不錯，但優化一下可以運行的更好)。
二、通過性能調優來了解底層原理
什麼時候需要性能調優 （when）
作爲我們程序員時時刻刻都應該對自己寫的代碼負責，不讓自己的代碼成爲應用的瓶頸。
什麼地方需要性能調優？（where）
之前說來性能調優就是調節這些內容，包括硬件、操作系統、應用程序。那麼調優地方當然是以下幾點嘍！
- 硬件選型(根據服務器應用類型來選購服務器)
- 操作系統調節系統參數
- 組件 (Nginx、MySQL等)
- 代碼
怎麼樣進行性能調優？（how）
- 性能指標 –> 確認衡量標準
- 性能測試 –> 驗證性能指標
- 性能分析 –> 找出性能瓶頸
- 性能調優 –> 解決性能問題
- 性能監控 –> 檢驗調優效果,重複第三步驟
性能指標
- 吞吐量
是單位時間內完成的用戶或系統的請求數量。 - 併發數
同時能接受多少用戶的訪問請求 - 響應時間
用戶發出請求到收到響應的時間間隔。 - 資源利用率
機器操作系統的資源利用
一般我們以上面的幾個指標評定軟件的性能。這幾個指標又有相互的制約，而我們需要尋找這樣一個各個指標都相對滿意的點。
響應時間--用戶併發數
響應時間一開始隨着用戶併發數的增加變化不大，當達到一個臨界值時陡升
吞吐量--用戶併發數
吞吐量一開始隨着用戶併發數的增加線性增長，當達到一個臨界值時吞吐量不在變化，再增加用戶併發數吞吐量出現下降
資源利用率--用戶併發數
資源利用率一開始隨着用戶併發數的增加線性增長，當達到一個臨界值時資源利用率達到飽和，不再變化
以上三張圖在做性能壓測時能很好的體現（這裏不講性能測試）。
硬件選型
硬件選型是在有限的資源下（金錢），選擇最適合自己應用運行的硬件基礎。（如果你是土豪那無所謂，反正貴總是有好處的）。
那麼如何選擇硬件呢？其實視自己在服務器上安裝的應用或則組件決定。
- 如果說是自己安裝個簡單的應用玩玩。那只需要購買能把應用跑起來，就差不多了。
- 如果要安裝個Mysql，那關注點是磁盤的轉數，cpu普通的就行
- 如果要安裝個緩存，比方Memcache，那關注點是內存大小，cpu普通就行（緩存可能還需要好的網絡，這個看你應用的瓶頸在哪）
- 如果要安裝個計算型的應用，那關注點是cpu，一般應用4G內存夠了
總的來說就是：應用或組件依賴什麼，那麼我們就多花點錢，配好的。也不需要富的流油，夠用就行
操作系統調節系統參數
操作系統Linux、windows，這些爲什麼還要調優呢？因爲操作系統不是爲你而設計的，而是爲大多數人設計的。它要適應大衆，才能普及推廣啊。
服務器一般都是Linux操作系統，不過我對操作系統不是很熟。所以下面只講我調節過的點。
系統句柄
Linux是有文件句柄限制的，一般都是1024，生產服務器用其實很容易就達到這個數量 是不是碰到過這些錯誤
java.lang.OutOfMemoryError:Unable to create new native thread
Can’t open so many files
too many open files
一個線程一個句柄，在高壓情況下，線程數量超過了服務器的句柄限制
- 查看當前使用的句柄數
cat /proc/sys/fs/file-nr
- 查看服務器句柄配置
ulimit -n
ulimit -a
- 設置句柄數
vi /etc/security/limits.conf
* soft noproc 65535
* hard noproc 65535
* soft nofile 65535
* hard nofile 65535
說明：* 代表針對所有用戶
noproc 是代表最大進程數
nofile 是代表最大文件打開數
修改完重新登錄就可以見到，使用 ulimit -a 查看確認
交換區
swap空間是一塊磁盤空間，操作系統使用這塊空間保存從內存中換出的操作系統不常用page數據，這樣可以分配出更多的內存做page cache。頁面頻繁換入換出會產生IO讀寫、操作系統中斷，這些都很影響系統的性能。
所以在內存充足的情況下最好關閉
swapoff -a
組件
組件是支稱應用性能的關鍵，所以選組件、配置參數至關重要
選組件
在強大的開源社區下，不同部位的組件可以有很多種選擇。比如緩存有memcache、redis、tair、aerospike等，看得我們是眼花繚亂。其實它們有不同的特性，我相信開發者不肯能重複的造輪子，它們各有各適合的場景。而你是以你所面臨的場景去選擇它們。
以下是我選取組件的步驟
1、清楚的瞭解自己所面臨的場景
2、根據場景抽取關鍵詞，去google搜索。（因爲自己的知識面不夠廣闊，不知道到底有哪些組件）
3、去官網查看它們的優點缺點,特意把缺點標黑，最會踩坑的地方
4、縮小組件範圍
5、動手基準測試，有些東西官網很能吹的
6、深入瞭解
不過公司已經大面積使用的情況下，是不容許你更換組件的。那麼我們只能依從，更關注使用方式和參數配置上去調節。
應用代碼
代碼調優，網上有很多。但是能熟練掌握不是一件容易的事，需要自己去嘗試（我也還在積累經驗的階段）。不過最近我發現思想上的改變很重要，下面講一下思想上的進步
首先我們要正視自己，我們現在處於什麼階段。我們需要腳踏實地，不要想着一開始就完美。我看過一本《程序員進階攻略》把我思想洗腦了下
階段
以下三個階段都是我們在開發上的流程，其實也是我們程序員的程度階段。
調試代碼Debugging
第一層含義：調試代碼或者不熟悉API
第二層含義：初入程序員行業，都是小心翼翼的。對自己寫的代碼不自信，需要不斷的調試來糾正自己
編寫代碼Coding
第一層含義：編寫業務代碼
第二層含義：能獨自完成業務代碼，在實現需求的情況下追求可讀性、可維護性。
運行代碼Running
第一層含義：運行代碼
第二層含義：在自己的腦袋中能運行程序，考慮到不同場景下的程序運行狀況
所以理解來自己在哪一個階段，在看下下一個階段的要求，再去追求。當達到了，在進行下一個目標。（怎麼跟實現夢想一樣啊，先分解目標）
定位性能問題
之前的話由於監控系統沒有，都是自己敲命令查詢（好心酸，後來我也給他們搞了個監控系統）。下圖是主要的一些命令
