1.mysql和redis的區別
mysql是一種關係型資料庫，資料會最終儲存在磁碟上。而redis是一種非關係型的nosql資料庫，以key-value的形式儲存資料，將資料儲存在記憶體。從效能上來說，redis將資料儲存在記憶體，性
能肯定要優於mysql資料庫。但是從安全的角度來說，mysql資料儲存在磁碟上更安全些。所以我們在專案中一般會將redis和mysql結合使用。
2.redis的事物
redis事物執行過程說明:redis對事物的支援比較簡單，能夠保證乙個客戶端發起的多個命令可以被連續的執行。我們清楚，在redis中和事物相關的關鍵字有multi（表示開啟乙個事物），
exec（表示執行乙個事物），discard（表示回滾乙個事物）。在一般情況下（沒有開啟事物），redis的client端發起乙個命令到redis的server端，命令會直接執行並將結果返回給client。但是
當我們使用multi開啟乙個事物時，client每發出乙個操作，server端會將這個命令放入到乙個佇列裡面，直到客戶端發出exec提交命令時，server端會將這些命令一次執行。並將執行的結果打包
傳送到client，結束這個事物的執行。
我們清楚關係型資料庫mysql的事物一般支援acid，即原子性，一致性，隔離性，永續性原則，但是在redis中，這些原則並不都支援。
原子性：在上面的分析中，我們已經清楚，乙個client端執行multi命令開啟乙個事物，會進入到乙個事物的上下文，之後所有的命令會被放到執行佇列，直到發出exec命令後，server端會依次執行這
些命令並將執行結果返回，並且釋放上下文。但是在這裡面有乙個問題，就是當佇列中有乙個命令出現錯誤時，並不會發生回滾，而是會繼續執行後面的命令。這就違背了事物的原子性原
則。這是redis事物存在的第乙個問題。
一致性：
隔離性：redis在執行乙個事物佇列中的命令時，其它的client是無法執行命令的，所以它滿足了隔離性。
永續性：通過前面對事物的分析，我們已經清楚redis的事物只不過是執行佇列中儲存的一系列的命令，執行完成之後資料依然儲存在記憶體。它的永續性其實與事物並沒有多大的關係，而是與我
們所設定的redsi的持久化方案有關。當我們沒有啟用redis的持久化時，所有資料都是儲存在記憶體，當然不存在永續性。當我們使用rdb模式的持久化方案時，如果在redis事物執行完成之後到執
行rdb檔案更新這段時間伺服器出現問題，事物提交的資料的永續性也無法得到保證。當我們使用aof模式的持久化方案時，命令的執行由主線程來完成，持久化由後台執行緒來完成，但是主線程不
會阻塞等待後台執行緒完成任務後在執行，中間出現時間差，所以也不一定會保證永續性。
redis事物存在的問題:
1.無法滿足原子性，佇列中某條命令執行錯誤時，並不會回滾，而是會繼續執行下面的命令。
2.假如我們在乙個事物執行之前查詢出乙個key，然後在這個事物中對這個key執行加1的操作。但是我們在事物提交(exec)之前某個客戶端對這個key做了修改，由此我們就無法達到我們的要
求。redis在這塊所做的努力是引入watch機制，我們在獲取key之前，對這個key執行watch命令，然後執行事物中，只要這個key發生任何的變化，這個事物不會執行成功。
MySQL資料庫之併發控制
無論何時，只要有多個查詢需要在同一時刻修改資料，都會產生併發控制的問題。本章的目的是討論mysql在兩個層面的併發控制 伺服器層與儲存引擎層。併發控制是乙個內容龐大的話題，有大量的理 獻對其進行過詳細的論述。本章只是簡要地討論mysql是如何併發讀寫的，因此讀者需要有相關的知識來理解本章接下來的內容...
資料庫 併發控制與鎖機制
事務隔離級別 資料庫中的事務是併發操作的，併發操作可以提高系統的工作效率，節省資源。在事務併發操作時，會出現多個事務對某一資源的爭用，多個事務對資源進行不同的操作，若不加以控制，會出現資料不一致的問題。因此，在dbms中需要進行併發控制管理。若不對併發事務進行控制，會出現資料不一致的問題，如髒讀 不...
資料庫之併發控制排程
序列 兩個事務分別執行，假設兩個事務t1和t2，分別的執行過程為 t1，t2 或 t2，t1 即先執行完t1再執行t2，或先執行t2再執行t1，事務的中間操作沒有交叉。可序列化 兩個事務執行的結果和事務序列執行的結果相同，注意，這裡更側重的是結果相同。衝突 每個事務可簡化為一組針對資料庫物件的rea...