public function getredis()
$redis = $this->getredis();
$key = 'str:name';
// 字串快取實戰
$redis->set($key, 'wxiangqian');
$name = $redis->get($key);
echo $name; // wxiangqian
$redis->expire($strcachekey, 30); # 設定30秒後過期
$key = 'hset:name'
$uid = 1;
$redis->hset($key, $uid, 'wxiangqian');
$data = $redis->hget($key, 1);
print_r($data); //輸出資料
$strkey = 'zset:ranking_list';
//儲存資料
$redis->zadd($strkey, '50', json_encode(['name' => 'tom']));
$redis->zadd($strkey, '70', json_encode(['name' => 'john']));
$redis->zadd($strkey, '90', json_encode(['name' => 'jerry']));
$redis->zadd($strkey, '30', json_encode(['name' => 'job']));
$redis->zadd($strkey, '100', json_encode(['name' => 'liming']));
$dataone = $redis->zrevrange($strkey, 0, -1, true);
echo "---- 由大到小的排序 ----
";print_r($dataone);
$datatwo = $redis->zrange($strkey, 0, -1, true);
echo "
---- 由小到大的排序 ----
";print_r($datatwo);
$strkey = 'list:data';
$page = $request->input('page',1);
$pagesize = $request->input('limit',50);
$limit_s = ($page-1) * $pagesize;
$limit_e = ($limit_s + $pagesize) - 1;
$data = $tools->redis->lrange($strkey,$limit_s,$limit_e);
print_r($data);
每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖。
場景：如果專案中使用了快取且對快取設定了超時時間。
當併發量比較大的時候，如果沒有鎖機制，那麼快取過期的瞬間，
大量併發請求會穿透快取直接查詢資料庫，造成雪崩效應。
/**
* 獲取鎖
* @param string $key 鎖標識
* @param int $expire 鎖過期時間
* @return boolean
*/public function lock($key = '', $expire = 5)
}return $is_lock? true : false;}
/** * 釋放鎖
* @param string $key 鎖標識
* @return boolean
*/public function unlock($key = '')
// 定義鎖標識
$key = 'str:lock';
// 獲取鎖
$is_lock = lock($key, 10);
if ($is_lock) else
每次去拿資料的時候都認為別人不會修改，所以不會上鎖。
watch命令會監視給定的key，當exec時候如果監視的key從呼叫watch後發生過變化，則整個事務會失敗。
也可以呼叫watch多次監視多個key。這樣就可以對指定的key加樂觀鎖了。
注意watch的key是對整個連線有效的，事務也一樣。
如果連線斷開，監視和事務都會被自動清除。
當然了exec，discard，unwatch命令都會清除連線中的所有監視。
$strkey = 'str:age';
$redis->set($strkey,10);
$age = $redis->get($strkey);
echo "---- current age: ----
"; // 10
$redis->watch($strkey);
// 開啟事務
$redis->multi();
//-------------------------------
/** * 在這個時候新開了乙個新會話執行
* * redis-cli 執行 $redis->set($strkey,30); //新會話 模擬其他終端
* 這時候$age=30; //30
*///-------------------------------
$redis->set($strkey,20);
$redis->exec();
$age = $redis->get($strkey);
echo "---- current age: ----
"; //30
//當exec時候如果監視的key從呼叫watch後發生過變化，則整個事務會失敗
悲觀鎖：比較適合寫入操作比較頻繁的場景，如果出現大量的讀取操作，每次讀取的時候都會進行加鎖，這樣會增加大量的鎖的開銷，降低了系統的吞吐量。
樂觀鎖：比較適合讀取操作比較頻繁的場景，如果出現大量的寫入操作，資料發生衝突的可能性就會增大，為了保證資料的一致性，應用層需要不斷的重新獲取資料，這樣會增加大量的查詢操作，降低了系統的吞吐量。
總結：兩種所各有優缺點，讀取頻繁使用樂觀鎖，寫入頻繁使用悲觀鎖。像樂觀鎖適用於寫比較少的情況下，即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生衝突，上層應用會不斷的進行retry，這樣反倒是降低了效能，所以這種情況下用悲觀鎖就比較合適,之所以用悲觀鎖就是因為兩個使用者更新同一條資料的概率高，也就是衝突比較嚴重的情況下，所以才用悲觀鎖.
悲觀鎖比較適合強一致性的場景，但效率比較低，特別是讀的併發低。樂觀鎖則適用於讀多寫少，併發衝突少的場景
redis基礎篇——redis安裝
redis基礎篇——介紹以及了解
redis基礎篇——基本用法
redis高階篇——php連線redis
redis-php實戰篇——常用的使用場景
spring aop 實戰篇 一
需求 通過spring aop 提供的面向切面程式設計的思想，利用自定義註解的方式，實現對介面的功能的增強 一 自定義乙個註解類 target 指明了修飾的這個註解的使用範圍，即被描述的註解可以用在 documented retention retentionpolicy.runtime targe...
（二）zookeeper實戰篇
a.安裝jdk b.安裝zookeeper 通過filezilla將zookeeper傳到linux下的 opt software下並chaos u x zookeeper 3.4.10.tar.gz 然後解壓到 opt module 下 c.修改配置 將 opt module zookeeper ...
效能測試 實戰篇
bug的表現 拆分物件 然後從功能實現上來看，怎麼實現這個完整功能的。通常這些業務功能操作都對應著乙個或多個請求 可能能是不同型別的請求，比如 http,mysql 等 我們要做的是找出這些操作對應的請求，請求之間的順序是怎麼樣的。指標分析 常用分析思路 2 8 法則 正態分佈 按比例倍增 響應時間...