【文章內(nèi)容簡(jiǎn)介】 mistic Locking)。 悲觀鎖 (Pessimistic Locking) 悲觀鎖，正如其名，它指的是對(duì)數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來(lái)自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度，因此，在整個(gè)數(shù)據(jù)處理過(guò)程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫(kù)提供的鎖機(jī)制（也只有數(shù)據(jù)庫(kù)層提供的鎖機(jī)制才能 真正保證數(shù)據(jù)訪(fǎng)問(wèn)的排他性，否則，即使在本系統(tǒng)中實(shí)現(xiàn)了加鎖機(jī)制，也無(wú)法保證外部系統(tǒng)不會(huì)修 15 改數(shù)據(jù)）。 一個(gè)典型的倚賴(lài)數(shù)據(jù)庫(kù)的悲觀鎖調(diào)用： select * from account where name=39。Erica39。 for update 這條 sql 語(yǔ)句鎖定了 account 表中所有符合檢索條件 (name=39。Erica39。)的記錄。 本次事務(wù)提交之前（事務(wù)提交時(shí)會(huì)釋放事務(wù)過(guò)程中的鎖），外界無(wú)法修改這些記錄，所有的修改請(qǐng)求將等待直到事務(wù)提交或回滾。 而在 Oracle 中有 for update nowait 關(guān)鍵字，當(dāng)發(fā)現(xiàn)數(shù)據(jù)被別的 session for update nowait鎖定中的時(shí)候，就會(huì)迅速返回 ORA00054錯(cuò)誤，內(nèi)容是資源正忙 , 但指定以 NOWAIT 方式獲取資源。所以在程序中我們可 以采用 nowait 方式迅速判斷當(dāng)前數(shù)據(jù)是否被鎖定中，如果鎖定中的話(huà)，就要采取相應(yīng)的業(yè)務(wù)措施進(jìn)行處理。 樂(lè)觀鎖 (Optimistic Locking) 對(duì)悲觀鎖而言，樂(lè)觀鎖機(jī)制采取了更加寬松的加鎖機(jī)制。悲觀鎖大多數(shù)情況下依靠數(shù)據(jù)庫(kù)的鎖機(jī)制實(shí)現(xiàn)，以保證操作最大程度的獨(dú)占性。但隨之而來(lái)的就是數(shù)據(jù)庫(kù)性能的大量開(kāi)銷(xiāo)，特別是對(duì)長(zhǎng)事務(wù)而言，這樣的開(kāi)銷(xiāo)往往無(wú)法承受。如一個(gè)金融系統(tǒng)，當(dāng)某個(gè)操作員讀取用戶(hù)的數(shù)據(jù)，并在讀出的用戶(hù)數(shù)據(jù)的基礎(chǔ)上進(jìn)行修改時(shí)（如更改用戶(hù)帳戶(hù)余額），如果采用悲觀鎖機(jī)制，也就意味著整個(gè)操作過(guò)程中（從操作員讀 出數(shù)據(jù)、開(kāi)始修改直至提交修改結(jié)果的全過(guò)程，甚至還包括操作員中途去煮咖啡的時(shí)間），數(shù)據(jù)庫(kù)記錄始終處于加鎖狀態(tài)，可以想見(jiàn)，如果面對(duì)幾百上千個(gè)并發(fā)，這樣的情況將導(dǎo)致怎樣的后果。樂(lè)觀鎖機(jī)制在一定程度上解決了這個(gè)問(wèn)題。樂(lè)觀鎖，大多是基于數(shù)據(jù)版本 (Version)記錄機(jī)制實(shí)現(xiàn)。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個(gè)版本標(biāo)識(shí)，在基于數(shù)據(jù)庫(kù)表的版本解決方案中，一般是通過(guò)為數(shù)據(jù)庫(kù)表增加一個(gè)version字段來(lái)實(shí)現(xiàn)。 相讀取出數(shù)據(jù)時(shí)，將此版本號(hào)一同讀出，之后更新時(shí)，對(duì)此版本號(hào)加一。此時(shí)，將提交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)庫(kù)表對(duì)應(yīng)記錄的當(dāng)前版本 信息進(jìn)行比對(duì)，如果提交的數(shù)據(jù)版本號(hào)大于數(shù)據(jù)庫(kù)表當(dāng)前版本號(hào)，則予以更新，否則認(rèn)為是過(guò)期數(shù)據(jù)。對(duì)于上面修改用戶(hù)帳戶(hù)信息的例子而言，假設(shè)數(shù)據(jù)庫(kù)中帳戶(hù)信息表中有一個(gè) version 字段，當(dāng)前值為 1 ；而當(dāng)前帳戶(hù)余額字段（ balance ）為 $100 。 1 操作員 A 此時(shí)將其讀出（ version=1 ），并從其帳戶(hù)余額中扣除 $50 （ $100$50 ）。 2 在操作員 A 操作的過(guò)程中，操作員 B 也讀入此用戶(hù)信息（ version=1 ），并從其帳戶(hù)余額中扣除 $20 （ $100$20 ） 。 3 操作員 A 完成了修改工作，將數(shù)據(jù)版本號(hào)加一（ version=2 ），連同帳戶(hù)扣除后余 16 額（ balance=$50 ），提交至數(shù)據(jù)庫(kù)更新，此時(shí)由于提交數(shù)據(jù)版本大于數(shù)據(jù)庫(kù)記錄當(dāng)前版本，數(shù)據(jù)被更新，數(shù)據(jù)庫(kù)記錄 version 更新為 2 。 4 操作員 B 完成了操作，也將版本號(hào)加一（ version=2 ）試圖向數(shù)據(jù)庫(kù)提交數(shù)據(jù)（ balance=$80 ），但此時(shí)比對(duì)數(shù)據(jù)庫(kù)記錄版本時(shí)發(fā)現(xiàn)，操作員 B 提交的數(shù)據(jù)版本號(hào)為 2 ，數(shù)據(jù)庫(kù)記錄當(dāng)前版本也為 2，不滿(mǎn)足 “ 提交版本必須大于記錄當(dāng)前版本才能 執(zhí)行更新 “ 的樂(lè)觀鎖策略，因此，操作員 B 的提交被駁回。 這樣，就避免了操作員 B 用基于 version=1 的舊數(shù)據(jù)修改的結(jié)果覆蓋操作員 A的操作結(jié)果的可能。從上面的例子可以看出，樂(lè)觀鎖機(jī)制避免了長(zhǎng)事務(wù)中的數(shù)據(jù)庫(kù)加鎖開(kāi)銷(xiāo)（操作員 A 和操作員 B 操作過(guò)程中，都沒(méi)有對(duì)數(shù)據(jù)庫(kù)數(shù)據(jù)加鎖），大大提升了大并發(fā)量下的系統(tǒng)整體性能表現(xiàn)。 結(jié)論 總之，介紹了數(shù)據(jù)庫(kù)的鎖定機(jī)制，究竟是悲觀鎖好還是樂(lè)觀鎖好，其實(shí)也是不一定的，跟開(kāi)發(fā)的技術(shù)、應(yīng)用的場(chǎng)景和具體的需求都有關(guān)系。在 Oracle 中悲觀鎖還是很不錯(cuò)的，而且從開(kāi)始的時(shí) 候就把數(shù)據(jù)鎖定。免除了后面的很多沖突處理。不過(guò)悲觀鎖需要保持一個(gè)Oracle 連接，在我們常見(jiàn)的 B/S 應(yīng)用中，特別是數(shù)據(jù)先取得，然后讓用戶(hù)再更新，再返回提交這種流程來(lái)說(shuō)，悲觀鎖是不大可能的。首先是因?yàn)?B/S應(yīng)用中，一般是利用一個(gè)連接池，在兩次 Http Request請(qǐng)求都是不同的數(shù)據(jù)庫(kù) Connection。而且也不能鎖定一個(gè)數(shù)據(jù)太長(zhǎng)時(shí)間，否則人人都這么鎖定，應(yīng)用很容易進(jìn)入死鎖狀態(tài)，這個(gè)時(shí)候就要采用樂(lè)觀鎖了。 (三 ) 多用戶(hù)的角色及權(quán)限的實(shí)現(xiàn)方法。 用戶(hù)的角色及權(quán)限的控制需要根據(jù)項(xiàng)目的實(shí)際情況和具體架構(gòu)來(lái)定，在 維護(hù)性、靈活性、完整性等 N 多個(gè)方案之間比較權(quán)衡，選擇符合的方案。對(duì)于在企業(yè)環(huán)境中的訪(fǎng)問(wèn)控制方法，一般有三種： 自主型訪(fǎng)問(wèn)控制方法。目前在我國(guó)的大多數(shù)的信息系統(tǒng)中的訪(fǎng)問(wèn)控制模塊中基本是借助于自主型訪(fǎng)問(wèn)控制方法中的訪(fǎng)問(wèn)控制列表 (ACLS)。 強(qiáng)制型訪(fǎng)問(wèn)控制方法。用于多層次安全級(jí)別的軍事應(yīng)用。 基于角色的訪(fǎng)問(wèn)控制方法（ RBAC）。是目前公認(rèn)的解決大型企業(yè)的統(tǒng)一資源訪(fǎng)問(wèn)控制的有效方法。其顯著的兩大特征是： ，降低管理開(kāi)銷(xiāo)。 支持企業(yè)的安全策略，并對(duì)企業(yè)的變化有很大的 伸縮性。 根據(jù)本項(xiàng)目的特點(diǎn)，優(yōu)先選用基于角色的用戶(hù)訪(fǎng)問(wèn)控制 (RBAC)。訪(fǎng)問(wèn)控制系統(tǒng)可以為應(yīng)用系統(tǒng)建立一個(gè)高安全強(qiáng)度， 更易維護(hù)管理， 擴(kuò)展能力極強(qiáng)的訪(fǎng)問(wèn)控制環(huán)境，并能夠有效的控制管理的復(fù)雜性，提供標(biāo)準(zhǔn)化和可以不斷延伸授權(quán)平臺(tái)。訪(fǎng)問(wèn)控制系統(tǒng)的體系結(jié)構(gòu)設(shè) 17 計(jì)保證了用戶(hù)能按照應(yīng)用規(guī)模和數(shù)量快速地建立訪(fǎng)問(wèn)控制體系。 完全基于策略思想設(shè)計(jì)的權(quán)限管理控制系統(tǒng)作為構(gòu)建訪(fǎng)問(wèn)控制體系的基石， 它能使用戶(hù)已建立的訪(fǎng)問(wèn)控制體系不斷滿(mǎn)足演化的應(yīng)用權(quán)限需求，如支持新應(yīng)用、支持新的權(quán)限、增加用戶(hù)數(shù)量、增加用戶(hù)類(lèi)型、增加策略數(shù)量等。 本系統(tǒng)在用戶(hù)訪(fǎng)問(wèn)控制管理中將引入角色的概念， 即在系統(tǒng)中提供若干個(gè)角色，每個(gè)角色的權(quán)限可以任意定制，在每一個(gè)角色下可以包含若干個(gè)用戶(hù)，用戶(hù)只能夠使用本角色允許使用的系統(tǒng)功能，對(duì)用戶(hù)無(wú)權(quán)使用的系統(tǒng)功能可以設(shè)置其狀態(tài)為不可見(jiàn)或隱藏。管理員可以首先分配好各個(gè)角色的權(quán)限，然后將系統(tǒng)的用戶(hù)分配到各個(gè)不同角色中，即可以完成用戶(hù)權(quán)限的設(shè)定，而不用逐個(gè)的去設(shè)定用戶(hù)的使用權(quán)限。 角色的概念 在現(xiàn)實(shí)生活中經(jīng)常提到某人扮演了什么角色。在基于用戶(hù)角色的用戶(hù)權(quán)限管理中，角色與實(shí)際的角色概念有所不同。在這里角色可以看作是一組操作的集 合，不同的角色具有不同的操作集，這些操作有系統(tǒng)管理員分配給角色。用戶(hù)的授權(quán)是通過(guò)授予用戶(hù)一個(gè)角色來(lái)實(shí)現(xiàn)的，即賦予用戶(hù)一個(gè)角色，一個(gè)用戶(hù)可以承擔(dān)不同的角色，從而實(shí)現(xiàn)授權(quán)的靈活性。只要某用戶(hù)屬于某個(gè)角色那么他就具備這個(gè)角色的所有操作許可，即該角色所擁有的權(quán)限。用戶(hù)與角色是多對(duì)多的關(guān)系。即一個(gè)用戶(hù)可以屬于多個(gè)角色之中，一個(gè)角色可以包括多個(gè)用戶(hù)。 RBAC 模型構(gòu)件分析 圖 RBAC 模型 我們對(duì)該模型定義如下： U， R， P， S：用戶(hù)；角色，權(quán)限，會(huì)話(huà)； PA P*R：權(quán)限分配，多對(duì)多的關(guān)系； UA U*R：用戶(hù)分配，多對(duì)多關(guān)系； User:SU,每一個(gè)會(huì)話(huà) s 對(duì)應(yīng)單一用戶(hù) user(s)的映射； Roles:會(huì)話(huà) s 到角色集合 role(s) {r|(user(s),r)∈ PA} 18 顯而易見(jiàn)：該模型由三個(gè)實(shí)體組成，分別是：用戶(hù)（ U）、角色（ R）、權(quán)限 (P)。其中用戶(hù)指自然人；角色就是組織內(nèi)部一件工作的功能或工作的頭銜，表示該角色成員所授予的職責(zé)的許可，系統(tǒng)中擁有權(quán)限的用戶(hù)可以執(zhí)行相應(yīng)的操作。 用戶(hù)與角色之間以及角色與權(quán)限之間用雙雙箭頭相連表示用戶(hù)角色分配 UA 和角色權(quán)限分配 PA 關(guān)系都是多對(duì)多的關(guān)系，即一個(gè)用戶(hù)可以擁有多個(gè)角色，一個(gè)角色也可被多個(gè)用戶(hù)所擁有。同樣的，一個(gè)角色擁有多個(gè)權(quán)限，一個(gè)權(quán)限能被多個(gè)角色所擁有。用戶(hù)建立會(huì)話(huà)從而對(duì)資源進(jìn)行存取，每個(gè)會(huì)話(huà) S 將一個(gè)用戶(hù)與他所對(duì)應(yīng)的角色集中的一部分建立映射關(guān)系，這個(gè)角色會(huì)話(huà)子集稱(chēng)為會(huì)話(huà)激活的角色集。于是，在這次會(huì)話(huà)中，用戶(hù)可以執(zhí)行的操作就是該會(huì)話(huà)激活的角色集對(duì)應(yīng)的權(quán)限所允許的操作。 RBAC 特點(diǎn)及應(yīng)用優(yōu)勢(shì) RBAC 幾大特點(diǎn) （ 1）訪(fǎng)問(wèn)權(quán)限與角色相關(guān)聯(lián)，不同的角色有不同的權(quán)限。用戶(hù)以什么樣的角色對(duì)資源進(jìn)行訪(fǎng)問(wèn)，決定了用戶(hù)擁有的 權(quán)限以及可執(zhí)行何種操作。 （ 2）角色繼承。角色之間可能有互相重疊的職責(zé)和權(quán)力，屬于不同角色的用戶(hù)可能需要執(zhí)行一些相同的操作。 RBAC 采用角色繼承的概念，如角色 2 繼承角色 1，那么管理員在定義角色 2 時(shí)就可以只設(shè)定不同于角色 1 的屬性及訪(fǎng)問(wèn)權(quán)限，避免了重復(fù)定義。 （ 3）最小權(quán)限原則，即指用戶(hù)所擁有的權(quán)力不能超過(guò)他執(zhí)行工作時(shí)所需的權(quán)限。實(shí)現(xiàn)最小特權(quán)原則，需要分清用戶(hù)的工作職責(zé)，確定完成該工作的最小權(quán)限集，然后把用戶(hù)限制在這個(gè)權(quán)限結(jié)合的范圍之內(nèi)。一定的角色就確定了其工作職責(zé)，而角色所能完成的事物蘊(yùn)涵了其 完成工作所需的最小權(quán)限。 用戶(hù)要訪(fǎng)問(wèn)信息首先必須具有相應(yīng)的角色， 用戶(hù)無(wú)法饒過(guò)角色直接訪(fǎng)問(wèn)信息。 （ 4）職責(zé)分離。一般職責(zé)分離有兩種方式：靜態(tài)和動(dòng)態(tài)。 （ 5）角色容量。在一個(gè)特定的時(shí)間段內(nèi)，有一些角色只能有一定人數(shù)的用戶(hù)占用。在創(chuàng)建新的角色時(shí)應(yīng)該指定角色的容量。 RBAC 應(yīng)用優(yōu)勢(shì) 最突出的優(yōu)點(diǎn)在于系統(tǒng)管理員能夠按照不同的安全政策劃分不同的角色，執(zhí)行特定的任務(wù)。一個(gè)系統(tǒng)建立起來(lái)后主要的管理工作即為授權(quán)或取消用戶(hù)的角色。 用戶(hù)的職責(zé)變化時(shí)只需要改變角色即可改變其權(quán)限；當(dāng)組織功能變化或演進(jìn)時(shí)，則只需刪除角色 的舊功能，增加新功能，或定義新角色，而不必更新每一個(gè)用戶(hù)的權(quán)限設(shè)置。這極大的簡(jiǎn)化了授權(quán)管理，使對(duì)信息資源的訪(fǎng)問(wèn)控制能更好地適應(yīng)特定單位的安全策略。 19 RBAC 另一優(yōu)勢(shì)體現(xiàn)在為系統(tǒng)管理員提供了一種比較抽象的、 與企業(yè)通常業(yè)務(wù)管理性類(lèi) 似的訪(fǎng)問(wèn)控制層次。通過(guò)定義、建立不同的角色、角色的繼承關(guān)系、角色之間的聯(lián)系以及相 應(yīng)的限制、管理員可動(dòng)態(tài)或靜態(tài)地規(guī)范用戶(hù)的行為。 在本項(xiàng)目中，各個(gè)功能模塊中的操作可以定義為各個(gè)獨(dú)立的權(quán)限集合中的元素，于是各個(gè)模塊其實(shí)就成了各自獨(dú)立的權(quán)限集合，平臺(tái)超級(jí)管理員可以預(yù)先定義好包含不同 權(quán)限集合的用戶(hù)角色，比如平臺(tái)超級(jí)管理員可以將平臺(tái)上公共信息平臺(tái)的添加、刪除、修改和查詢(xún)等權(quán)限賦予平臺(tái)公共信息管理員這個(gè)角色；而在平臺(tái)上租用應(yīng)用服務(wù)的公司的管理員用戶(hù)角色就擁有對(duì)公司部門(mén)的訂制權(quán)限，下屬用戶(hù)帳號(hào)的管理操作權(quán)限等等。 系統(tǒng)中的各級(jí)管理員就可以將預(yù)先定義好的用戶(hù)角色再分配各自的下級(jí)用戶(hù)帳號(hào)，比如下訂單員工的帳號(hào)就賦予下訂單的系統(tǒng)角色，分管信息的帳號(hào)就分配以信息管理員的角色。這里不同的帳號(hào)也可以分配相同的用戶(hù)角色以方便完成任務(wù)，上級(jí)的管理員則是擁有下屬用戶(hù)的所有角色權(quán)限。這樣通過(guò)基于角色的訪(fǎng)問(wèn)控制（ RBAC）實(shí)現(xiàn)本平臺(tái)中多用戶(hù)角色權(quán)限的訪(fǎng)問(wèn)控制。 一個(gè)安全的網(wǎng)絡(luò)需要可靠的訪(fǎng)問(wèn)控制作保障。在網(wǎng)絡(luò)規(guī)模變大、用戶(hù)增多、需求更復(fù)雜 的情況下，傳統(tǒng)的訪(fǎng)問(wèn)控制已經(jīng)不能滿(mǎn)足許多企業(yè)或組織的安全需要，基于角色的訪(fǎng)問(wèn)控制（ RBAC）便明顯地顯示出其優(yōu)越性。基于角色的訪(fǎng)問(wèn)控制可以很好的解決資源庫(kù)項(xiàng)目的訪(fǎng)問(wèn)控制，為系統(tǒng)開(kāi)發(fā)提供了一套有力的工具，還為用戶(hù)評(píng)估系統(tǒng)提供了標(biāo)準(zhǔn)。 (四 ) 關(guān)于大型應(yīng)用平臺(tái)高并發(fā)量的技術(shù)處理。 負(fù)載均衡將是大型網(wǎng)站解決高負(fù)荷訪(fǎng)問(wèn)和大量并發(fā)請(qǐng)求采用的終極解決辦法。 負(fù)載均衡技術(shù)發(fā)展了多年，有很多專(zhuān)業(yè)的 服務(wù)提供商和產(chǎn)品可以選擇， 根據(jù)我們 接觸