前兩天看binlog發現個奇怪的地方：對於position靠後的記錄，timestamp卻比之前的記錄還要小。當時覺得大概和併發有關係
後來做了個實驗
開兩個session
對於session1：
begin;
insert into t1 values(1);
insert into t1 values(3);
insert into t1 values(5);
此時在session2：
begin;
insert into t1 values(2);
insert into t1 values(4);
commit;
然後再在session1:
insert into t1 values(7);
commit;
觀察binlog
# at 22101158
#150702 20:31:27 server id 1 end_log_pos 22101230 query thread_id=1234 exec_time=0 error_code=0
set timestamp=1435894287/*!*/;
begin
/*!*/;
# at 22101230
#150702 20:31:13 server id 1 end_log_pos 22101316 query thread_id=1234 exec_time=0 error_code=0
set timestamp=1435894273/*!*/;
insert t1 values(2)
/*!*/;
# at 22101316
#150702 20:31:14 server id 1 end_log_pos 22101402 query thread_id=1234 exec_time=0 error_code=0
set timestamp=1435894274/*!*/;
insert t1 values(4)
/*!*/;
# at 22101402
#150702 20:31:24 server id 1 end_log_pos 22101488 query thread_id=1234 exec_time=0 error_code=0
set timestamp=1435894284/*!*/;
insert t1 values(6)
/*!*/;
# at 22101488
#150702 20:31:27 server id 1 end_log_pos 22101515 xid = 480617
commit/*!*/;
# at 22101515
#150702 20:31:32 server id 1 end_log_pos 22101587 query thread_id=1232 exec_time=0 error_code=0
set timestamp=1435894292/*!*/;
begin
/*!*/;
# at 22101587
#150702 20:30:52 server id 1 end_log_pos 22101673 query thread_id=1232 exec_time=0 error_code=0
set timestamp=1435894252/*!*/;
insert t1 values(1)
/*!*/;
# at 22101673
#150702 20:30:55 server id 1 end_log_pos 22101759 query thread_id=1232 exec_time=0 error_code=0
set timestamp=1435894255/*!*/;
insert t1 values(3)
/*!*/;
# at 22101759
#150702 20:30:56 server id 1 end_log_pos 22101845 query thread_id=1232 exec_time=0 error_code=0
set timestamp=1435894256/*!*/;
insert t1 values(5)
/*!*/;
# at 22101845
#150702 20:31:18 server id 1 end_log_pos 22101931 query thread_id=1232 exec_time=0 error_code=0
set timestamp=1435894278/*!*/;
insert t1 values(7)
/*!*/;
# at 22101931
#150702 20:31:20 server id 1 end_log_pos 22102017 query thread_id=1232 exec_time=0 error_code=0
set timestamp=1435894280/*!*/;
insert t1 values(9)
/*!*/;
# at 22102017
#150702 20:31:30 server id 1 end_log_pos 22102104 query thread_id=1232 exec_time=0 error_code=0
set timestamp=1435894290/*!*/;
insert t1 values(11)
/*!*/;
# at 22102104
#150702 20:31:32 server id 1 end_log_pos 22102131 xid = 480613
commit/*!*/;
可以看到session2的事務因為更早提交，所以position更靠前，但是因為請求時間比較晚，所以timestamp落後於session1所提交的事務
php高併發狀態下檔案的讀寫
背景 1 對於pv不高或者說併發數不是很大的應用，不用考慮這些，一般的檔案操作方法完全沒有問題 2 如果併發高，在我們對檔案進行讀寫操作時，很有可能多個程序對進一檔案進行操作，如果這時不對檔案的訪問進行相應的獨佔，就容易造成資料丟失 對於這樣的問題，一般的解決方案 1 當一程序對檔案進行操作時，首先...
高併發狀態下快取失效及其解決辦法
專案中使用redis快取，會存在各種各樣的問題，例如快取沒有命中，沒有查到資料，快取沒有使用到，這一系列的問題，簡單的說就是 快取穿透，快取雪崩，快取擊穿 快取穿透當查詢乙個一定不存在的資料，由於快取中沒有這個資料，所以將會去資料庫中查詢，但是資料庫中也沒有這個資料，而我們在資料庫查詢到為null的...
讀 寫鎖的實現和應用（高併發狀態下的map實現）
程式中涉及到對一些共享資源的讀和寫操作，且寫操作沒有讀操作那麼頻繁。在沒有寫操作的時候，兩個執行緒同時讀乙個資源沒有任何問題，所以應該允許多個執行緒能在同時讀取共享資源。但是如果有乙個執行緒想去寫這些共享資源，就不應該再有其它執行緒對該資源進行讀或寫 譯者注 也就是說 讀 讀能共存，讀 寫不能共存，...