星動力X和昇三大會館節目全集 共10段

石門旗艦會館:主持人:琳妲、曲曲

金礦餐旅會館:主持人:許薇安、湘閔、呼呼、Q匠

陽明山攬月溫泉會館:主持人:佩佩、小佩

張貼在 星動力節目全播映 | 標記 , , , , , , , | 發表留言

不要使用memcached存儲Session的建議

Memcached創建者Dormando很早就寫過兩篇文章 [文1] [文2] ,告誡開發人員不要用memcached存儲Session。他在第一篇文章中說的理由大致是說,如果用memcached存儲Session,那麽當memcached集群發生故障(比如內存溢出)或者維護(比如升級、增加或減少服務器)時,用戶會無法登錄,或者被踢而掉線。而在第二篇文章中,他則指出,memcached的回收機制可能會導致用戶無緣無故地掉線了啊!

Titas Norkūnas是DevOps咨詢服務提供商Bear Mountain的聯合創始人。由於看到Ruby/Rails社區忽略了Dormando那兩篇文章所指出的問題,所以他近日撰文對此進行了進一步的闡述。他認為問題的根本在於,memcached是一個設計用於「緩存數據」而不是「存儲數據」的系統,因此不應該用於存儲Session。

對於Dormando的那兩篇文章,他認為第一篇文章給出的原因很容易理解,而人們經常會對第二篇文章給出的原因認識不足。因此他對這個原因進行了詳細地闡述:

Memcached使用“最近最少使用(LRU)”算法回收緩存。
但memcached的LRU算法是針對每個slab類執行,而不是針對整體。

這意味著,如果所有Session的大小大致相同,
那麽它們會分成兩三個slab類。
所有其它大小大致相同的數據也會放入同一些slab,
與Session爭用存儲空間。
一旦slab滿了,即使更大的slab中還有空間,
數據也會被回收,而不是放入更大的slab中…
在特定的slab中,Session最老的用戶將會掉線。
用戶將會開始隨機掉線,
而最糟糕的是,你很可能甚至都不會註意到它,
直至用戶開始抱怨…

另外,Norkūnas提到,如果Session中增加了新數據,那麽Session變大也可能會導致掉線問題出現。

有人提出將Session和其它數據分別使用單獨的memcached緩存。不過,由於memcached的LRU算法是局部的,那種方式不僅導致內存使用率不高,而且也無法消除用戶因為Session回收而出現隨機掉線的風險。

如果你真的非常希望借助memcached提高Session讀取速度,那麽可以借鑒Norkūnas提出的memcached+RDBMS的模式(在有些情況下,NoSQL也可以):

※ 當用戶登錄時,將Session “set”到memcached,並寫入數據庫;
※ 在Session中增加一個字段,標識Session最後寫入數據庫的時間;
※ 每個頁面加載的時候,優先從memcached讀取Session,其次從數據庫讀取;
※ 每加載N頁或者Y分鐘後,再次將Session寫入數據庫;
※ 從數據庫中獲取過期Session,優先從memcached中獲取最新數據。

以上就是,必須好好思考,

再來就是進行實作測試的階段了啊!

的確值得令人深思…

靜思…

緩思…

真的必須…

多方面考慮才行啊…

… 思考也是很累的…

必須…休息一下子啊…

難道是真的不建議嗎? 真的不要嘛?memcached不要用來存session...

難道是真的不建議嗎? 真的不要嘛?memcached不要用來存session…

張貼在 午夜編碼區 | 標記 , , , , , , , | 2 則迴響

PHPEXCEL 輸出EXCEL錯誤、中文亂碼、檔案格式與副檔名不符等等各種解法

PHPEXCEL 輸出EXCEL錯誤亂碼、檔案格式與副檔名不符等等幾種問題的解法

以上,其實是各種不同的問題。

如果是輸出中文亂碼的問題,乃編碼之故也,PHP程式本身的編碼設定就不用說了,另外在PHPEXCEL方面的輸出表頭設定方面請參考

$filename = urlencode("TEST.xls");
ob_end_clean();
header("Content-type: text/html; charset=utf-8");
header("Content-Type: application/vnd.ms-excel");
header("Content-Disposition: attachment;filename=".$filename);

$objWriter=PHPExcel_IOFactory::createWriter($PHPExcel,'Excel5');
$objWriter->save('php://output');
exit;

其中有utf-8的編碼設定,
ob_end_clean() 清除緩衝區的內容。

另外,還有iconv()的使用,
比如說我上次就有一個輸出excel中文亂碼,
解法是先用
$name = iconv(“UTF-8″,"BIG5″, $name);
然後$name再給PHPEXCEL寫入表格,
然後就可以輸出正常顯示囉!

以上各項這些都會有幫助解決的功效。

但是,我遇過一次是PHPEXCEL輸出是檔案格式整個錯誤,看起來像是中文亂碼,但其實不是顯示亂碼的問題,以上所述的解法都完全無效,經過爬文一個晚上之後,終於在國外網站看到洋人大德提供的一個檢查,那就是自己這一個PHP程式的標頭 <?php 在這前面是否發現任何的空格或是空行呢?? 這就會導致錯誤!果然,發現了在最上面還空了兩行!馬上將 <?php 頂到最頂之後,PHPEXCEL輸出果然就正確了啊!

搞了一個晚上,這種算是低級錯誤嗎? 應該也算吧! 但是真的讓人想不到竟然會有這種問題啊!所以寫程式,真的要養成好習慣啊~~

所以,不可免俗的,依照本部落格的傳統,還是要來慰勞一下啊!如果要往下拉的話,必須慢慢滴、慢滿滴…

..

..

..

..

..

..

..

..

..

..

慰勞一下啊!辛苦研究、反覆測試後的身心紓解啊~

KOREA BEAUTY

 

張貼在 午夜編碼區 | 標記 , , , , , , , , , , | 發表留言

兩部老舊實機PC來架設Cassandra Cluster

cassandra 多節點示意圖 Cassandra Ring

cassandra 4個節點變成8個節點 —  Cassandra Ring

早就想幹了!!

幹…幹什麼?運用多實機電腦架設卡珊卓分佈式資料庫啦…

之前用"虛擬機"docker玩cassandra和opscenter,雖然是好玩,但一定是隔靴搔癢的,而且只是練習用的吧?這次,終於擠出了時間(就是其他事情都不管了啊),準備了兩部老舊的電腦,來測試架設 cassandra cluster ,沒錯!2個真正的實體node就可以證明這一切!

● 兩部皆為CentOS

● 兩部將要安裝cassandra 2.1版(po文目前最新版)

● 檢查 # java –version,需要java 7以上

今天此系統為DataStax公司所出,所以先新增DataStax 的repository才能yum install
新增檔案:

# vi  /etc/yum.repos.d/datastax.repo

內容:

[datastax]
name = DataStax Repo for Apache Cassandra
baseurl = http://rpm.datastax.com/community
enabled = 1
gpgcheck = 0

存檔。

繼續,

● 使用yum install ,兩部server皆安裝

# yum install dsc21
# yum install cassandra21-tools

什麼叫做dsc21?那就是DataStax Cassandra 2.1版!


● 安裝完成後,測試一下是否能正常為您服務

# service cassandra start 或 stop 或 restart 或 status
ok的,沒問題

ok的,沒問題

● 接下來注意 iptables防火牆,剛裝好CentOS時,它預設的規則,就會擋掉接下來的連線測試,所以請處理一下規則或是關閉,以繼續往下進行。

● 好,接著繼續,

先將兩部cassandra給它們STOP

# service cassandra stop

然後清除資料

# rm -rf /var/lib/cassandra/data/system/*

 

● 先來設定第一部 node 1 也就是SEED 的 cassandra.yaml 初始設定

(SEED IP 是192.168.1.129 )

開始編輯修改yaml

#   vi /etc/cassandra/default.conf/cassandra.yaml

內容裡面含有以下項目( 粗體字為非預設,需自行設定修改)

cluster_name: ‘TestCluster‘

num_tokens: 256

seed_provider:

-class_name: org.apache.cassandra.locator.Simple

-SeedProvider parameters:

-- seeds: "192.168.1.129"

-listen_address: 192.168.1.129

-rpc_address: 192.168.1.129

-endpoint_snitch: GossipingPropertyFileSnitch

然後啟動它!第一部seed總是要先啟動是也!

# service cassandra start

 

● 接著再進行第2部 node 2  的 cassandra.yaml 初始設定

node 2 的IP 是192.168.1.136

編輯修改yaml

#   vi /etc/cassandra/default.conf/cassandra.yaml

其中含有以下項目( 粗體字為非預設,需自行設定)

cluster_name: ‘TestCluster‘

num_tokens: 256

seed_provider:

-class_name: org.apache.cassandra.locator.Simple

-SeedProvider parameters:

-- seeds: “192.168.1.129”   # (註)

-listen_address: 192.168.1.136

-rpc_address: 192.168.1.136

-endpoint_snitch: GossipingPropertyFileSnitch

(註) seeds當然是設定SEED IP,如果有多個seed,則用逗號隔開,如:"192.168.1.129,192.168.1.130″

ok 好了,啟動之!

# service cassandra start

使用 # nodetool status 看看 ,可見到連續這兩個node,已經組在一起了!

如其所言,沒有指定要看哪個keyspace的Owns欄,是沒有意義的,所以是問號。

(注意:如果防火牆規則有擋掉的話,在這裡就會出現怪怪的錯誤,比如說UN變成DN:down,Load也變成問號….)


好吧!那就來新建一個keyspace和旗下的一個table吧!

剛才偶綿在yaml 裡面有一個rpc_address設定,那就是cqlsh的入口了,指令下法:

# cqlsh 192.168.1.129  或是  # cqlsh 192.168.1.136

要在哪一部server 去cqlsh哪一個ip來創建、修改或查詢都行啦,總之結果都是一樣滴。

( 如果防火牆規則有擋掉的話,這裡也會出現錯誤了)

創建過程省略,test_keyspace.test_table的內容有了:

ok,那好!來吧!

# nodetool status test_keyspace

就可以見到這一個test_keyspace在2個node之分佈大略情況了,什麼是意義?這就是意義!

nodetoolsss

nodetool 工具組還有很多參數指令可以下達,比如說,# nodetool info 就會出現:

又比如說 # nodetool  gossipinfo 提供我們這cluster gossip之資訊

除了提供很多資訊觀察之外,nodetool還有不少修復、控制、重建等等各項功能。

更多爆多的nodetool utility官方文件在這裡,約有四五十個。

好啊!!

從頭到尾、花許多間try and error(註)、邊做邊截圖、寫文稿,如此整整忙了兩天,終於在過年前可以鬆一口氣了,有點成就感,倒是不錯的。

註: why?? 因為按照現行DataStax官方文件的範例,一些關鍵處ip是不需要設定,只要留空白,它說系統自動會抓,結果咧,執行結果是錯誤的,cluster根本起不來,還是需要自己手動去設定ip,才ok了。說到這一點,官方文件大可不需要為了好像系統很聰明會自動抓,而示範說啊這裡不用填,啊那裡填0.0.0.0就可以,結果哩?結果還不是抓不到?它不如就老老實實地示範,在什麼位置就是手動設定什麼ip就好,我們就多打幾個數字而已,不會浪費許多時間在那假設這個錯誤在哪裡?在那邊一直try & error …

而事已至此,不能免俗滴,辛勞心勞(腦勞)工作後的犒賞時間又到了,敬請稍微注意身旁週遭的人事狀況,再往下拉…

用腦過度,累了吧!補充一杯牛奶,放鬆休息一下好嗎?

用腦過度,累了吧!補充一杯牛奶,放鬆休息一下好嗎?

好啦!這個還好啦~ 比較溫腥喔~

張貼在 午夜編碼區 | 標記 , , , , , , , , , | 2 則迴響

docker 運用 OpsCenter 監控 Cassandra cluster

opscenter、cassandra、docker,相信搜尋到這一篇的玩家們,應該都知道是什麼東西,就不多做解釋了。

( CentOS , docker : poklet/cassandra )

之前有一篇記錄了使用docker建立5 nodes的簡易步驟

手動建立還是很有成就感的,現在就來建立3個node吧!

首先,建立第一個,名喚: cass1

# docker run -d --name cass1 poklet/cassandra start

然後查詢一下cass1它的ip…就是SEED IP

# SEED_IP=$(docker inspect -f '{{ .NetworkSettings.IPAddress }}' cass1)

還是看一下ip到底是多少

# echo $SEED_IP

這次是 172.17.0.5

接著建立第二、第三個node,寫法如….依此類推

# docker run -d --name cass2 poklet/cassandra start $SEED_IP

# docker run -d --name cass3 poklet/cassandra start $SEED_IP

好吧 先建三個,然後看一下狀況: nodetool status

# docker run -i -t --rm poklet/cassandra nodetool -h $SEED_IP status

如下:

node_status_okok

如果要用cqlsh操作資料庫,則是:

# docker run -i -t poklet/cassandra cqlsh $SEED_IP

好的,接下來是來測試opscenter

首先,安裝

# docker pull poklet/opscenter

啟動也!

# docker run -d --name opscenter -p 8888:8888 poklet/opscenter

其中 -p 8888:8888 就是 host的port 和 container的port 之對接

比如說 host 的ip 是 192.168.1.129

(docker container “opscenter"的ip 則是 :

# OPS_IP=$(docker inspect -f ‘{{ .NetworkSettings.IPAddress }}’  opscenter)

)

那麼 http://192.168.1.129:8888 就可以打開這docker 的 opscenter了,選擇管理既存的Cluster :

ops0

輸入這一次的 SEED IP :

ops1

成功進入Dash board,可以看到有3個node,但是尚未綁定agent,所以NO DATA

ops2

選擇Nodes進入觀看,可以見到 Cassandra Ring,有三個node,沒有錯

為了綁定三個agent,點選原來Dashboard上方藍色的Fix,會出現:

ops3

點選Enter Credentials

agent使用SSH,輸入root或是sudo特權之帳密,接著再進行install node

ops4 ops5

目前到以上為止都很順利,明明顯示進度都正常,但接下來就有問題了,竟然發現每一個node的agent都已經一一顯示已經綁定了,然後過了幾秒之後,又都反悔了!顯示尚未綁定,失敗…

測試了幾次…革命尚未成功,但是轉念一想,為何要用docker虛擬機來玩cassandra cluster呢? 還不就是因為要練習多節點叢集架設和監控,想說一次架5個、10個node來測試看看。但是,使用docker虛擬機的問題,無法像"實體"一樣進行全面的細部的設定,就比如說docker這個開了3個cassandra,那又要如何去分別針對它們3個ip instance 去調整設定cassandra.yaml 呢?  (其中每一個的rpc_address、listen_address等等…) 似乎是沒有辦法。

只是說,docker這種超輕量的一杯牛奶虛擬機,還真的滿好玩的,非常有意思。

停止 和 刪除 所有docker container之指令,不需要一個一個去刪啊!

# docker stop $(docker ps -a -q) 

# docker rm $(docker ps -a -q)

話說回來,偶滴手邊雖然沒有五台、十台真實電腦,但也有兩三部舊電腦,安裝"實體"的Linux CentOS minimal – Cassandra 來做,也很ok的啊!一定要把OpsCenter監控測試成功,如此感受到的確是非常熱血啊!馬上開始動工,下一篇來看結果吧!

確定沒人在旁 再往下拉比較好一點點

這也是一種鼓勵啊!

 

張貼在 午夜編碼區 | 標記 , , , , , , , | 發表留言

TCP/IP、Http、Socket 來探討一下

話說網路七層論,由下往上分為物理層、鏈結層、網絡層、傳輸層、會話層、表現層和應用層。

IP協議對應於網絡層,TCP協議對應於傳輸層,而HTTP協議對應於應用層,三者從本質上來說是完全不同。

socket則是對TCP/IP協議的封裝和應用(程序員層面上)。

也可以說,TPC/IP協議是傳輸層協議,主要解決數據如何在網絡中傳輸,

而HTTP是應用層協議,主要解決如何包裝數據。

關於TCP/IP和HTTP協議的關係,以下是比較容易理解的介紹:

“我們在傳輸數據時,可以只使用(傳輸層)TCP/IP協議,但是那樣的話,如果沒有應用層,便無法識別數據內容。

如果想要使傳輸的數據有意義,則必須使用到應用層協議。

應用層協議有很多,比如HTTP、FTP、TELNET等,也可以自己定義應用層協議。

WEB使用HTTP協議作應用層協議,以封裝HTTP文本信息,然後使用TCP/IP做傳輸層協議將它發到網絡上。”

而我們平時說的最多的socket是什麽呢,實際上socket是對TCP/IP協議的封裝,Socket本身並不是協議,而是一個調用接口(API)。

通過Socket,我們才能使用TCP/IP協議。

實際上,Socket跟TCP/IP協議沒有必然的聯系。

Socket編程接口在設計的時候,就希望也能適應其他的網絡協議。

所以說,Socket的出現只是使得碼農更方便地使用TCP/IP協議棧而已,是對TCP/IP協議的抽象,而形成了一些最基本的函數接口,比如create、listen、connect、accept、send、read和write等等。

接著再來理解一下:

“TCP/IP只是一個協議,就像操作系統的運行機制一樣,必須要具體實現,同時還要提供對外的操作接口。

這個就像操作系統會提供標準的編程接口,比如win32編程接口一樣,

TCP/IP也要提供可供程序員做網絡開發所用的接口,這就是Socket編程接口。”

網路上有個比較形象的描述:HTTP是轎車,提供了封裝或者顯示數據的具體形式,Socket是發動機,提供了網絡通信的能力。

實際上,傳輸層的TCP是基於網絡層的IP協議的,而應用層的HTTP協議又是基於傳輸層的TCP協議的,而Socket本身不算是協議,就像上面所說,它只是提供了一個針對TCP或者UDP編程的接口。

下面是一些經常碰到的重要概念,特在此做摘抄總結:

一、什麽是TCP連接的三次握手

第一次握手:客戶端發送syn包(syn=j)到服務器,並進入SYN_SEND狀態,等待服務器確認;

第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN_RECV狀態;

第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手。

握手過程中傳送的包裏不包含數據,三次握手完畢後,客戶端與服務器才正式開始傳送數據。

理想狀態下,TCP連接一旦建立,在通信雙方中的任何一方主動關閉連接之前,TCP 連接都將被一直保持下去。

斷開連接時服務器和客戶端均可以主動發起斷開TCP連接的請求,斷開過程需要經過“四次握手”(過程就不細寫了,就是服務器和客戶端交互,最終確定斷開)

二、利用Socket建立網絡連接的步驟

建立Socket連接至少需要一對套接字,其中一個運行於客戶端,稱為ClientSocket ,另一個運行於服務器端,稱為ServerSocket 。

套接字之間的連接過程分為三個步驟:服務器監聽,客戶端請求,連接確認。

1、服務器監聽:服務器端套接字並不定位具體的客戶端套接字,而是處於等待連接的狀態,實時監控網絡狀態,等待客戶端的連接請求。

2、客戶端請求:指客戶端的套接字提出連接請求,要連接的目標是服務器端的套接字。

為此,客戶端的套接字必須首先描述它要連接的服務器的套接字,指出服務器端套接字的地址和端口號,然後就向服務器端套接字提出連接請求。

3、連接確認:當服務器端套接字監聽到或者說接收到客戶端套接字的連接請求時,就響應客戶端套接字的請求,建立一個新的線程,把服務器端套接字的描述發給客戶端,一旦客戶端確認了此描述,雙方就正式建立連接。

而服務器端套接字繼續處於監聽狀態,繼續接收其他客戶端套接字的連接請求。

三、HTTP的特點

HTTP協議即超文本傳送協議(Hypertext Transfer Protocol ),是Web聯網的基礎,也是手機聯網常用的協議之一,HTTP協議是建立在TCP協議之上的一種應用。

HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束後,會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。

四、TCP和UDP的區別

1、TCP是面向鏈接的,雖然說網絡的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性,但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了連接的可靠性;

而UDP不是面向連接的,UDP傳送數據前並不與對方建立連接,對接收到的數據也不發送確認信號,發送端不知道數據是否會正確接收,當然也不用重發,所以說UDP是無連接的、不可靠的一種數據傳輸協議。

2、也正由於1所說的特點,使得UDP的開銷更小數據傳輸速率更高,因為不必進行收發數據的確認,所以UDP的實時性更好。

因此,UDP因為在底層協議的封裝上沒有采用類似TCP的“三次握手”而實現了TCP所無法達到的較高速傳輸效率。

這一篇只能到這裡為止了

因為,越往底層去探討,那就會越挖越多…

挖都挖不完….何處是個頭啊?

光是去鑽研一下TCP/IP的事情就會出現浩瀚巨冊的學問啊~~

至少我們可以體會到網路架構之形成,是一層一層又一層,大家通力合作,各司其職搭建,才有今天的成就啊!學而時習之,真正是好啊!

….

各司其職通力合作,網路一層又一層

各司其職通力合作,網路一層又一層

….

張貼在 午夜編碼區 | 標記 , , , , , , , | 發表留言

[Linux CentOS6.5筆記]新裝好後,啟動網卡超方便一步搞定 eth0

這一陣子因為要架設實作cassandra node cluster系統,接受某一位低調的大師指導使用docker,心中覺得非常感恩啊!大師首選CentOS 6.5 minimal版本,因此偶也開始對此產生了濃厚的興趣。

只有300多MB的ISO檔來安裝完成,這種純文字命令列,親手輸入叫電腦做事的感覺…真的有回到國中時期玩APPLE II和MS-DOS那種…帶給人非常神秘的一種特殊的電腦數位快感啊!(這樣…應該沒有很變態吧?)

好的,回到主題,小筆記。CentOS6.5安裝好後,網路預設是不通的。因此我們要啟動一下網卡 eth0,超方便,只要 vi 一下這個:

/etc/sysconfig/network-scripts/ifcfg-eth0

將裡面原本ONBOOT=no 改成 yes

no改成yes就搞定了

no改成yes就搞定了

然後再重啟系統 reboot,網路就通了!

就這麼簡單啊!但是也有人這樣改了也是通不了的,聽說目前的CentOS6.6曾經發生過?這…就不太清楚了!

注意啊!先確定您身旁沒有不該出現的人再往下拉啊~

..

..

..

網路通了,可以開始做事了啊!快去做事吧!

no都改成yes了。網路通了,可以開始做事了啊!快去做事吧!

張貼在 午夜編碼區 | 標記 , , , , | 發表留言