http://health.msn.com.cn/healthcare/20110603/05001247621.shtml
保健：七種食物抗癌效果好
茄子 “霜打茄子”是好藥 。越來越多證據表明，茄子具有抗癌功能。曾有試驗從茄子中提取的一種無毒物質，用于治療胃癌、子宮頸癌等收到良效。
苦瓜 苦瓜是不可多得的抗癌瓜。苦瓜種子中含有一種蛋白酶抑制劑，能抑制腫瘤細胞分泌蛋白酶，從而抑制癌細胞的侵襲和轉移。
海帶 海帶中藥名為“昆布”，可預防乳腺癌和甲狀腺腫瘤。海帶可殺滅或抑制腸道內能夠產生致癌物的細菌，所含的纖維還能促進膽汁酸和膽固醇的排出；海帶提取物對各種癌細胞有直接抑制作用。
地瓜 地瓜是人們逐漸淡忘的抗癌佳品。別名甘薯、紅薯、白薯，被認為是祛病延年、減肥保健的絕佳食品。其實地瓜能預防腸癌和乳腺癌的發生。
麥麩 麥麩是最好的防癌食物纖維，它能預防并治療結直腸癌、糖尿并高膽固醇血癥、高脂血癥、便秘、痔瘡等。
蘿卜 蘿卜是根莖類蔬菜中的“健康保護神”。胡蘿卜因含豐富的胡蘿卜素，也具有極好的防癌作用。
獼猴桃 獼猴桃維生素C含量居水果之冠，是名副其實的“天然維生素C片”，另外還含有豐富的具有保護血管功能的維生素P，其營養價值甚高。
]]>
]]>
一：游戲服務器的作用：連接各個網游客戶端，實現各客戶端的通信，連接，數據操作
二：先從大分類上來：游戲服務器按一般架構來說具備1
1:登陸驗證注冊和賬號有關的所有操作的服務器 我們簡稱他為registerserver
2：游戲邏輯操作服務器 我們簡稱他為gameserver
不用細說大家也明白了，說一個玩家登陸進入游戲世界的流程：玩家打開游戲客戶端（這之前會有更新操作，不過這只是連接更新服務器的一個文件比對和下載過程，我們不將他列為游戲服務器之內）說到這里朋友會發現游戲登陸上目前有兩大類，一類是先選服務器后輸入賬號 一類是先輸入賬號后選服務器，這里說下區別
先選服務器后輸入賬號的一般來說都是將registerserver和gameserver配對，就是你先選擇服務器，而后你連接上的就是此服務器的registerserver，通過此registerserver來進行賬號驗證等等。另一類先輸入賬號的，無非是先制定一個中心registerserver（或者是隨機一個，因為register有時候會弄好多個由運維配置來做動態均衡），賬號驗證成功后再顯示服務器列表，然后玩家選擇了服務器后，則從指定服registerserver去數據庫查詢玩家此服的角色列表（當然了，這里如果非有人的服務器是做成查詢角色列表就從gameserver走的流程，我也沒意見）。返回后，客戶端進入角色選擇界面，客戶端與registerserver斷鏈，玩家選擇角色，與gameserver連接，去數據庫提取角色，注冊進入游戲服游戲世界，反饋角色信息給客戶端，客戶端進入游戲世界。然后消息發送過來發送過去的開始了。。。。。。
上面說的是針對一個普通的一對一架構的服務器所有的一個登陸流程，看到這里，朋友們應該對registerserver和gameserver的基本功能有所了解了。一個是登陸驗證用（垃圾點的小公司沒有注冊賬號的主頁的話也會通過這個在游戲里直接注冊賬號。。。）到登陸進入游戲世界的過程。
再稍微高級點的就是加個聊天服務器了，因為聊天這個功能實在是太耗性能了，特別那啥的那公聊，你發個一句，服務器得有多少人就發多少回。。。
打個比方你發一句話 50個字那就是100 一個服有那么個幾K人的話，就打比方5K人 一句話發送就得是一個全服人口大FOR循環，網絡還得消耗掉5000*100字節
所以你看各游戲公聊國聊那啥的都時間限制要不就收費，他扛不住啊。
所以這個地方就出來個性能優化方案了，加個聊天服務器，也就是玩家在登陸成功與gameserver連接成功的同時要與聊天服務器連接成功，聊天服務器有個全服在線角色表，一個大FOR循環和那啥的5000*100就讓他來發吧，至少對gameserver沒影響了。
好了，一個普通服務器的基本介紹就說到這里，讀者也應該有個基本了解了，具體架構上的就不細說了，趕明換個帖子發。這里還是接標題從功能上來分析服務器。
這里就只分析游戲服務器了，registerserver就不考慮了。
一個游戲服務器他的作用在與，所有的游戲數據操作都將在這里完成，我們將只將客戶端作為顯示和一個數據的完善緩存。一切的操作都必須在游戲服務器的驗證之后才能完成。
功能模塊分類（本人之間，有多余或遺漏的，歡迎補充）：
1：腳本模塊
2：屬性模塊
3：網絡模塊
4：數據庫模塊
5：日志模塊
以上所列的為一個完善的游戲服務器所必須實現的功能 下面一一來說
1：腳本模塊
沒有腳本模塊，腳本策劃就得喝西北風，LUA首選很不錯。
具體LUA的學習，推薦LUA程序設計，這玩意不用深究，會即可。
程序員要寫好幾個CPP，完成的功能是---》在C++中任意的調用LUA函數（或是執行一個LUA文件），在LUA中任意調用你提供給腳本策劃的C++函數接口，如此功能實現后，哈哈，程序員們，你們的工作負擔就輕了，很大一部分的邏輯編程將交給策劃們去完成了
舉例：程序實現一個接口例如 say(LPCSTR szSay) ，則策劃可調用此接口 function mySay() say("歡迎來到游戲世界") end，就可
可用到的地方：具體物品的使用邏輯，特殊任務的邏輯，活動邏輯，特殊NPC邏輯等等等等，只要你愿意，跑步都可用LUA來
比如C++里可實現一籃子接口：AddItem 增加個物品 ChangeMap 跳地圖 甚至是AddLevel等等 而由LUA調用此類接口，而后就是C++里做些操作，比如玩家點擊物品就是調用相應物品的腳本：例：點擊 血瓶 調用 LUA 的血瓶腳本，執行LUA函數調用AddHp
腳本模塊很重要，可極大的方便工作，還有調試和維護，因為修改腳本，服務器是不用重編譯的，則意味著可在調試中隨意修改，甚至可在運營過程中隨意修改某物品功能 某任務 某活動。。。，只需C++到LUA，把這個LUA函數RELOAD下即可
具體的游戲應用腳本的例子 大家網上找找吧 一坨子開源的。
2：屬性模塊：呵呵，不知道我取這個名字OK不OK，我也覺得不是很合適，大家又更好的命名沒？
NPC的基本屬性配置，物品的基本屬性配置，叫屬性配置可能更合適點，意思就是你要提供一個模塊供策劃可填入各個屬性配置，甚至是GUI的配置又或者是任務配置。對于這個，我推薦使用EXCEL表格。
例如：NPC的表格至少包括 NPC名字 模型編號 血量 藍量 移動速度 AI 等等，而后有策劃往里面隨意填配置 這里比如AI就是一個對應的腳本文件
這個讀取表格由程序員實現，功能是要求要自由化，不然的話 策劃加一條 你咋辦，不至于從讀取開始你的代碼都得改吧，肯定能做到直接在NPCPROPERTY結構體里直接加一條和表格新加的對應就OK了。
如果OK得話，最好再提供個編輯工具給策劃，任務的相同模式也可由此來實現：任務描述 任務要求 對話1 對話2 對話3 獎勵1 獎勵2 獎勵3
物品：物品名字 模型編號 職業 等級 攻擊 腳本
不然你總不至于傻到認為這些都是寫代碼里的吧。也可能有人想使用XML 隨便了 不過我這里不想用XML 為啥 EXCEL清晰啊 就一行條目
這個模塊是數值策劃 任務策劃的天下
3：網絡模快：這個沒啥好說的 一個基本功能，游戲世界都是在這之上也能成型，做好鏈接維護，收發消息
4：數據庫模塊：對數據的保存 其實這里我熱衷于使用工廠模式，本地調試服務器具體邏輯用本地文檔方式，上測試服上外網則用數據庫，所以這里叫數據操作模塊比較妥當點，就是玩家保存數據，保存幫派啦 等等世界信息的具體操作，這個很重要
5：日志模塊：我將此日志模塊分為兩大類，一類是游戲服務器調試維護用日志，一類是游戲運營用日志，可選擇使用本地文檔或是數據庫模式記錄
調試維護日志沒啥好說的，運營日志說說，是給客服提供的，誰消費了什么 交易流向 物品流向 等等的記錄 GM操作的記錄等等 比如萬一某玩家裝備被盜了，則可通過此來證明。
接著一繼續，其實寫本文從內行技術角度來看，本身就沒什么技術含量，但是俗話說的好，隔行隔山，內行看門道，外行那啥什么，反正就是想觸碰這玩意，但是又沒搞過的人看的。反正都是隨便亂寫了，愛看的看，準備寫個功能模塊大概 再寫個架構得大概，而后就去從網絡包開始搞個最簡單最輕量的小架構，力圖讓知道編程是啥的就能在上面搞東西
還是繼續談功能模塊。
一、還有個 AI模塊，這個可不能忘啊
不過要注意，我這里提到的AI模塊和我一里面所提到的幾個AI地方說指AI不是一會事情。
這里的AI模塊，哈哈，就是所謂的算法了，算法達人們NB的地方了。
針對NPC怪物等，比如最基本的尋路算法。
此模塊達到的效果是什么呢，就是：怪物死了又活，怪物看見你知道追你，怪物知道打你 都知道尋路躲障礙
介紹下最基本的A*算法吧 什么A B C D E F D的
怪物要打你 得追你，但是他為啥知道跟你走呢，或者說你點擊一個地方，為啥就能自動走過去，能自動的繞開障礙呢。這個模塊就是實現這些基本的東西。
2D的一般都是按格子計算，就說2D了，還有用像素玩的，3D玩坐標的，等等 其實都是一會事情
角色身旁一共有8個格子，你點擊一個地方，就等于是指明了一個方向，角色就找到正對方向的身旁最近格子，判斷此格子是否有阻擋，如果無則走過去，如果有阻擋則搜索身旁另一個格子，然后就是這么一直遞歸，知道到達終點格子。
基本的自動尋路算法就是上面這么一段話，當然實際操作中，肯定不會用這么費效率的算法了，這里就是簡單介紹下這個活在N-》B之前的N-》A*算法。。NA啊。具體的大家可以去找本人工智能的書看看
服務器要算一下怪物走哪了就給周圍玩家同步下消息，所以服務器需要這玩意，這理由充分吧、、、
客戶端也需要，給玩家或者寵物自動尋路，內掛使用。
為什么我說這里的AI和我在一里面說的不同呢，是因為這里是實行基本的自動功能，而后你可以在這個模塊的基礎上發展高級AI智能，結合腳本，表格配置，活用技能。比如一個游戲里按檔次有白怪 藍怪 紫怪 BOSS
白怪么就給他這一套最基本的會走路躲障礙會打人就可
藍怪 稍微高級點了，在基本模塊上擴展，程序里再實現血少到一定程度會逃跑 會喊同伙，
以上兩種可根據屬性配置表格模塊根據怪物類型讀取到程序，程序根據類型判斷是否激活擴展AI
表格可如下：
NPC名字 類型
紫怪 再高級點 定制AI，可在程序里預先定義一組高級AI，比如預先設想好的十種可能，打個比方，放A技能 放B技能 自動加血等等 ，而后也可在表格配置，比如預先表格設定好一種怪物最多可有4個定制AI
表格可如下：
NPC名字 類型 定制AI1 定制AI2 定制AI3 定制AI4
程序讀取到相應類型而激活相應模塊 或者此組AI 都用腳本預先寫好 也不錯 這樣比寫死在程序里好
BOSS 那就得完全特殊處理了不是，腳本發揮作用，完全腳本實現 程序事先一組接口，比如掉什么裝備接口，放技能的接口等等，LUA里面就狂寫吧，接口只要完善，寫成個WOW里的一樣也很OK
表格可如下：
NPC名字 類型 定制AI1 定制AI2 定制AI3 定制AI4 腳本AI
像2D游戲 下FB BOSS不夠智能的話 玩家就知道卡BOSS 幾個玩家把BOSS圍一圈，讓外面的遠程玩家打，格子上玩家又是不可重復的，BOSS就出不去 有仇恨系數 他又只想殺外面打他的玩家 導致就卡那里了，想打的玩家打不到 打的到的玩家又不想打。。。。。。。怎么辦呢，特殊AI處理，卡BOSS？系統判斷BOSS十秒不出手，就放大技能秒殺周圍的人。。。。
說到底，AI模塊就是最基本算法，程序定制，腳本定制，屬性表格配置再加腳本特殊化處理，基本就可達到需求了
二：擴展下前面說的數據庫模塊和日志模塊
這里大家要注意，在這類數據庫 和IO操作上 盡量使用別的線程來開，不要和主線程搞到一起
按目前流行的架構，一般都是在服務器上多開線程開啟網絡接口，另外在專門單開代理程序，消息發送到數據代理，讓代理來實現數據操作。
日志模塊，本地調試么，就用文檔記錄，運營日志，單開個代理吧，這個操作挺頻繁的，和登錄保存角色的代理放一起影響性能 而且每什么意思，畢竟這個異步互相是不關聯的 稍微提醒下就是 你要是做 物品流向的時候 切記不要所有物品都記啊 不然就SB了，這個流向日志 要是都記錄的話 那一天都不知道是多少萬條記錄了 萬？十萬？百萬？
可以 表格配置：
物品名字 物品ID 是否記錄日志 //后面其他列是其他屬性
每次產生物品流向時候 比如買一個裝備到包里 交易一個裝備 等等
if(pItemProperty->bCanSaveLog)
{
//sendmessagetologdb
}
這樣你就記錄些珍貴物品就可
按我的分類 我一般將代理分為 賬號代理 角色代理 游戲代理 日志代理 運維控制器代理
這里不一個個講了 放到后面說架構的時候再說每個代理需要做的事情
一個宗旨是 分的細 每一個得壓力就小 但是要保證不要出現數據互交叉
也見過某些項目 是沒有具體的數據操作代理的，直接是在服務器里直接操作，我個人認為啊，能新開進程 異步的 就開，沒必要給老板省錢，全部都壓一GAME上 扛不住啊，而且如果是分布式的話，你肯定得有一個統一的數據出口啊，不然的話。。我沒想過會怎樣，數據不統一？數據庫死鎖?
三：運維模塊
運維分開就是運營和維護。。 因為他們是走的同一套架構，所以這里就放一起來說
首先說明他們的產生原因：不可能每一次服務器更新 或者再監控服務器 維護過程 或者是提取某某文件日志 都是一個個遠程硬件服務器吧 那樣的話 維護者工作效率就太低了
GM也不可能每一個服務器都登陸進個客戶端開著吧。。所以這個模塊就產生了，對維護者是要實現他們的遠程操作，對GM是要實現他們的線下操作。
工具功能：可監控 開啟 關閉服務器 可主動推送更新文件 更新腳本
GM可線下操作基本命令，監控聊天，賠償物品，發送游戲郵件等等。
開發者可主動提取調試日志記錄
算帳的可主動開后臺查看運營日志記錄計算ARPU值，查看在線記錄，等等等等
我現在是不推薦GM做線上操作的呢，就如同之前傳奇那樣的，都是在聊天框里輸入GM命令，我個人認為內部操作還是走后門的好 不要和玩家一起從前門走了，注意的是這一塊在中心控制器代理這里一定要做好監控，和操作記錄，驗證，來保證操作的安全性，防止違規操作。力圖將工具客戶端綁定到某一臺機器，比如可在運維登陸工具時候 發送賬號 密碼 MACKEY IP 子網掩碼 某一個CODE 等等在控制中心驗證 成功才可登入控制中心，工具客戶端才可操作、
這個模塊主要注意的就是安全性，操作的方便，和日志模塊結合在一起，日志記錄 分類 挖掘 良好
具體架構的后面再說
畢竟這個就是淺談，所以沒有什么實際性的代碼內容，就是讓不了解的朋友能夠了解這是怎樣的一個架構一個工作流程
看了留言啊 ，這博客，不同IP，點了就加一閱讀，沒意思啊，我不知道到底有沒有價值繼續啊，
我是力圖用最淺的語言來表現這些玩意是怎么會事情，高深的我也不懂了，扁我吧，。覺得沒啥意思的也留個言拍下磚頭啊，覺得有意思的留個言讓我高興下，主要是沒打草稿直接寫的就發了，遺漏 不清不楚肯定還是有的 .
本文介紹一下一個應用的游戲服務器的架構和演變
游戲服務器的作用在于滿足在線玩家的需求，實現賬號的驗證，登陸，玩家在游戲世界的一系列邏輯操作和驗證。在此基礎上，一個好的架構，可以提升效率，在實現邏輯需求的情況下達到百萬級的同時在線數也不是不可能。
我們先從最搓的最簡單的結構看起
CLIENT ---------- SERVER --------- DBSYSTEM
就是一個很簡單的 C/S系統 同一個server同時處理登陸注冊創建角色和游戲邏輯操作的功能，。在server上直接掛接DB操作。DB可以是一個具體的數據庫也可以是一個FILESYSTEM
這里可以看的出來，過于簡單了，將登陸注冊創建和具體邏輯這幾個毫無關系的東西放置于一起，嚴重損耗了具體邏輯操作的效率，特別是在新開服階段，完全會因為登陸驗證的操作而導致邏輯爆卡。
所以這里需要升級，將完全不同類型在玩家一次游戲操作工程中只會在登陸階段執行一次的操作單獨分開，單獨進程解決，。故而可成為下面階段
- LOGINSERVER -
- -
CLIENT - - DBSYSTEM
- -
- GAMESERVER -
分為兩個服務器，這個我在一文章里的開頭就有提到過了。
我們來看下好處進階，在LOGINSERVER里只執行賬號驗證 查詢角色列表 創建角色的操作 而后玩家登陸進GAMESERVER 具體邏輯操作在GAMESERVER里完成
玩家的一次登陸操作
發送賬號 驗證 返回角色列表 創建角色
CLIENT---------------LOGINSERVER -----------DBSYSTEM-----------------------CLIENT ------------------
選擇角色與LOGIN斷鏈與GAME連接 登陸
LOGINSERVER -------DBSYSTEM ----------CLIENT ------------------------------------------------------GAMESERVER
如此，可有效的提升效率，玩家的驗證 列表讀取 創建 和GAME就毫無關系了，但是他的缺點任然存在 我們再繼續看可優化的地方
首先從數據庫上來提升效率（先說下，從這里開始就應該是肯定的是用數據庫了，而非什么本地FILE了，），將賬號庫和游戲數據庫分開，分離為兩個獨立的庫，
具體理由有兩個：
1：從游戲運營上來說 你不可能一直是只有一個服吧？ 分成多個服后 人數越來越多，就不能所有服都共用一個數據庫了吧？那你這數據庫也牛逼了
所以我們這里這么干，將 賬號庫獨立，全游戲共用，這樣是方便管理，方便管理賬號的全局性的信息 經濟性的 比如點卡什么的，每個服一個游戲數據庫，只記錄操作你這個服的玩家信息，世界信息。
2：理由類同將服務器拆分為LOGIN和GAME。
現在 結構就是這樣的
- LOGINSERVER-
- - ACCOUNTDBSYSTEM
CLIENT - -
- - GAMEDBSYSTEM
- GAMESERVER -
但是到了這里后 肯定還是不夠的，
我們先說個基本的，在服務器里 ，你一定要記得，數據庫操作，IO操作 ，文本操作這些 一定要單獨進程不要和主進程搞一起，你總不希望你做了個什么查詢還是什么操作 他主線程掛起吧？但是，試想下，如果能單獨進程肯定還是單獨進程更爽一點吧？你還能在里面做做緩存啥的，還不占服務器的資源
所以這里還是麻煩的 從效率上來說 至少后臺這塊 還有很大提升空間。因此，我們加入 DBAGENT模塊 ，單獨進程，將數據庫操作單獨分離，并且可自我添加某些應用的緩存
對應ACCOUNTDBSYSTEM 增加 accountagent ，對應 GAMEDBSYSTEM 增加 gameagent
結構如下
-LOGINSERVER-
- - accountagent - ACCOUNTDBSYSTEM
CLIENT -
- - gameagent - GAMEDBSYSTEM
-GAMESERVER -
LOGINSERVER同時和accountagent和gameagent連接 gameserver也同時和這兩個連接 服務器通過agent來對對應的數據庫做操作 因為accountdbsystem可能是全服共有的 ，所以accountagent也可以是全服共有的 他連接所有的服務器。loginserver通過accountagent來驗證 通過gameagent來查詢列表 創建角色 gameserver通過gameagent來查詢完整角色信息登陸進game，并通知accountagent此賬號已進入游戲，避免重復登陸。并且定期保存。設置你可以將比如你游戲的排行榜啊，拍賣行啊的信息放置于你自己設計的gameagent的緩存中，而避免重復查詢
玩家每一個對數據庫的操作 server只需發送消息到agent agent來做具體操作，而后再返回到server 再到client就可。將數據操作完全的異步操作，效率有較大提升。并且安全性上也得到了些許保證。
不是我胡說或者輕視，國內一大半游戲，都用的上面這個結構。。。。。。。。。。。。。。。。。。。。。這個可以算是一個比較完善的產品化架構了。
說到這里，大家有沒有發現一個共性。采用這類架構，游戲必然會是先選服務器再驗證賬號 登陸進游戲，這是因為服務端采用的是LOGIN和GAME一對一得處理，也就是你是登陸的什么服務器必然就是從什么服務器的LOGIN進入驗證，故而他需要在客戶端開啟的時候就要知道需要連接的是哪個LOGIN 賬號驗證成功后再是哪個GAME
其實這里很好處理，就在客戶端上做些處理就可以達到先登陸驗證在選服務器。所以在配置上 LOGIN不再是一對一（后面會有優化的再說到多個LOGIN），全局也共用一個LOGIN。玩家開啟客戶端，連接LOGIN。發送賬號驗證。因為這里已經是把ACCOUNTDBSYSTEM做成全局的了，所以是不用擔心他是哪個服的，然后返回成功，玩家客戶端顯示服務器列表（這個列表還有連接信息配置再客戶端就可以了）選擇某一個服后，則發送查詢某服角色列表的請求到LOGIN，而后再返回再登陸游戲就可。小小調整和改變就可實現先驗證后選服務器了。
所以，到了這步，服務器架構就變成這個樣子了
-LOGINSERVER-
- - accountagent -ACCOUNTDBSYSTEM
CLIENT - |--------
- |-----------
-
- GAMESERVER - gameagent -GAMEDBSYSTEM
- |
- GAMESERVER -gameagent -GAMEDBSYSTEM
全局共用一個LOGIN和一個ACCOUNTAGENT還有ACCOUNTDBSYSTEM
每個獨立服各自獨立的gameagent 和gamesdbystem
但是LOGIN的瓶頸立馬出現了，當初是一個服獨立一個LOGINSERVER 現在是全服只有一個了，毫無以為，扛不住。
其實上面這個架構的不一定非得存在的，就是隨便寫寫，讓大家更清楚一點。
所以LOGINSERVER就得配置多個了。這個地方大家選擇吧 盡量靈活點，可以全服單位的配置多個也可以每個服對應的配置多個LOGINSERVER。這樣 在開服時候，這種大面積井噴式的玩家玩家上線，可有效解決負載。具體CLIENT開啟后會是和哪個LOGIN連接呢
這里提供兩種方式。一個是配置上的 一個是程序上的
1：
程序上的好說 ，你把所有LOGINSERVER的連接信息都配置到客戶端，讓客戶端開啟后隨機選擇一個去連接。要是你開服后，他所有玩家都隨機到一個LOGINSERVER了，那真的算你點背。背到家了
2：配置上 ：
通過基于DNS的負載均衡系統，DNS中為一個域名配置多個IP地址。通過負載，讓系統來選擇是對應到哪個IP
所以就是
-LOGINSERVER -|
- LOGINSERVER -|
-LOGINSERVER -|
- -accountagent -ACCOUNTDBSYSTEM
CLIENT - |--------
- |-----------
-
-GAMESERVER -gameagent -GAMEDBSYSTEM
- |
-GAMESERVER - gameagent -GAMEDBSYSTEM
或者是：
- LOGINSERVER -
- LOGINSERVER -
- LOGINSERVER -
..................................上面可以是N個
- -gameagent -GAMEDBSYSTEM
-GAMESERVER -
Client
- LOGINSERVER -
- LOGINSERVER -
- LOGINSERVER -
..................................上面可以是N個
- gameagent-GAMEDBSYSTEM
- GAMESERVER -
accountagent -- --- ACCOUNTDBSYSTEM 是全局的
一個服對應好多個LOGINSERVER
因為LOGINSERVER使用的動態配置，故而可在登陸下線沒有多大壓力的情況下，關掉幾個LOGINSERVER，節省運維資源
不想寫了，元旦又混了三天，明天繼續吧。明天把前面的再擴展下，再說下分線的和分布的。牛逼的就不說了
]]>
http://www.asciitable.com/
]]>
1. ASCII碼
我們知道，在計算機內部，所有的信息最終都表示為一個二進制的字符串。每一個二進制位（bit）有0和1兩種狀態，因此八個二進制位就可以組合出 256種狀態，這被稱為一個字節（byte）。也就是說，一個字節一共可以用來表示256種不同的狀態，每一個狀態對應一個符號，就是256個符號，從 0000000到11111111。
上個世紀60年代，美國制定了一套字符編碼，對英語字符與二進制位之間的關系，做了統一規定。這被稱為ASCII碼，一直沿用至今。
ASCII碼一共規定了128個字符的編碼，比如空格“SPACE”是32（二進制00100000），大寫的字母A是65（二進制01000001）。這128個符號（包括32個不能打印出來的控制符號），只占用了一個字節的后面7位，最前面的1位統一規定為0。
2、非ASCII編碼
英語用128個符號編碼就夠了，但是用來表示其他語言，128個符號是不夠的。比如，在法語中，字母上方有注音符號，它就無法用ASCII碼表示。 于是，一些歐洲國家就決定，利用字節中閑置的最高位編入新的符號。比如，法語中的é的編碼為130（二進制10000010）。這樣一來，這些歐洲國家使 用的編碼體系，可以表示最多256個符號。
但是，這里又出現了新的問題。不同的國家有不同的字母，因此，哪怕它們都使用256個符號的編碼方式，代表的字母卻不一樣。比如，130在法語編碼 中代表了é，在希伯來語編碼中卻代表了字母Gimel (?)，在俄語編碼中又會代表另一個符號。但是不管怎樣，所有這些編碼方式中，0—127表示的符號是一樣的，不一樣的只是128—255的這一段。
至于亞洲國家的文字，使用的符號就更多了，漢字就多達10萬左右。一個字節只能表示256種符號，肯定是不夠的，就必須使用多個字節表達一個符號。 比如，簡體中文常見的編碼方式是GB2312，使用兩個字節表示一個漢字，所以理論上最多可以表示256x256=65536個符號。
中文編碼的問題需要專文討論，這篇筆記不涉及。這里只指出，雖然都是用多個字節表示一個符號，但是GB類的漢字編碼與后文的Unicode和UTF-8是毫無關系的。
3.Unicode
正如上一節所說，世界上存在著多種編碼方式，同一個二進制數字可以被解釋成不同的符號。因此，要想打開一個文本文件，就必須知道它的編碼方式，否則用錯誤的編碼方式解讀，就會出現亂碼。為什么電子郵件常常出現亂碼？就是因為發信人和收信人使用的編碼方式不一樣。
可以想象，如果有一種編碼，將世界上所有的符號都納入其中。每一個符號都給予一個獨一無二的編碼，那么亂碼問題就會消失。這就是Unicode，就像它的名字都表示的，這是一種所有符號的編碼。
Unicode當然是一個很大的集合，現在的規模可以容納100多萬個符號。每個符號的編碼都不一樣，比如，U+0639表示阿拉伯字母Ain，U+0041表示英語的大寫字母A，U+4E25表示漢字“嚴”。具體的符號對應表，可以查詢unicode.org，或者專門的漢字對應表。
4. Unicode的問題
需要注意的是，Unicode只是一個符號集，它只規定了符號的二進制代碼，卻沒有規定這個二進制代碼應該如何存儲。
比如，漢字“嚴”的unicode是十六進制數4E25，轉換成二進制數足足有15位（100111000100101），也就是說這個符號的表示至少需要2個字節。表示其他更大的符號，可能需要3個字節或者4個字節，甚至更多。
這里就有兩個嚴重的問題，第一個問題是，如何才能區別unicode和ascii？計算機怎么知道三個字節表示一個符號，而不是分別表示三個符號 呢？第二個問題是，我們已經知道，英文字母只用一個字節表示就夠了，如果unicode統一規定，每個符號用三個或四個字節表示，那么每個英文字母前都必 然有二到三個字節是0，這對于存儲來說是極大的浪費，文本文件的大小會因此大出二三倍，這是無法接受的。
它們造成的結果是：1）出現了unicode的多種存儲方式，也就是說有許多種不同的二進制格式，可以用來表示unicode。2）unicode在很長一段時間內無法推廣，直到互聯網的出現。
5.UTF-8
互聯網的普及，強烈要求出現一種統一的編碼方式。UTF-8就是在互聯網上使用最廣的一種unicode的實現方式。其他實現方式還包括UTF-16和UTF-32，不過在互聯網上基本不用。重復一遍，這里的關系是，UTF-8是Unicode的實現方式之一。
UTF-8最大的一個特點，就是它是一種變長的編碼方式。它可以使用1~4個字節表示一個符號，根據不同的符號而變化字節長度。
UTF-8的編碼規則很簡單，只有二條：
1）對于單字節的符號，字節的第一位設為0，后面7位為這個符號的unicode碼。因此對于英語字母，UTF-8編碼和ASCII碼是相同的。
2）對于n字節的符號（n>1），第一個字節的前n位都設為1，第n+1位設為0，后面字節的前兩位一律設為10。剩下的沒有提及的二進制位，全部為這個符號的unicode碼。
下表總結了編碼規則，字母x表示可用編碼的位。
Unicode符號范圍 | UTF-8編碼方式
(十六進制) | （二進制）
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
下面，還是以漢字“嚴”為例，演示如何實現UTF-8編碼。
已知“嚴”的unicode是4E25（100111000100101），根據上表，可以發現4E25處在第三行的范圍內（0000 0800-0000 FFFF），因此“嚴”的UTF-8編碼需要三個字節，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，從“嚴”的最后一個二進制位開始，依次從后向前填入格式中的x，多出的位補0。這樣就得到了，“嚴”的UTF-8編碼是 “11100100 10111000 10100101”，轉換成十六進制就是E4B8A5。
6. Unicode與UTF-8之間的轉換
通過上一節的例子，可以看到“嚴”的Unicode碼是4E25，UTF-8編碼是E4B8A5，兩者是不一樣的。它們之間的轉換可以通過程序實現。
在Windows平臺下，有一個最簡單的轉化方法，就是使用內置的記事本小程序Notepad.exe。打開文件后，點擊“文件”菜單中的“另存為”命令，會跳出一個對話框，在最底部有一個“編碼”的下拉條。
里面有四個選項：ANSI，Unicode，Unicode big endian 和 UTF-8。
1）ANSI是默認的編碼方式。對于英文文件是ASCII編碼，對于簡體中文文件是GB2312編碼（只針對Windows簡體中文版，如果是繁體中文版會采用Big5碼）。
2）Unicode編碼指的是UCS-2編碼方式，即直接用兩個字節存入字符的Unicode碼。這個選項用的little endian格式。
3）Unicode big endian編碼與上一個選項相對應。我在下一節會解釋little endian和big endian的涵義。
4）UTF-8編碼，也就是上一節談到的編碼方法。
選擇完”編碼方式“后，點擊”保存“按鈕，文件的編碼方式就立刻轉換好了。
7. Little endian和Big endian
上一節已經提到，Unicode碼可以采用UCS-2格式直接存儲。以漢字”嚴“為例，Unicode碼是4E25，需要用兩個字節存儲，一個字節 是4E，另一個字節是25。存儲的時候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。
這兩個古怪的名稱來自英國作家斯威夫特的《格列佛游記》。在該書中，小人國里爆發了內戰，戰爭起因是人們爭論，吃雞蛋時究竟是從大頭(Big- Endian)敲開還是從小頭(Little-Endian)敲開。為了這件事情，前后爆發了六次戰爭，一個皇帝送了命，另一個皇帝丟了王位。
因此，第一個字節在前，就是”大頭方式“（Big endian），第二個字節在前就是”小頭方式“（Little endian）。
那么很自然的，就會出現一個問題：計算機怎么知道某一個文件到底采用哪一種方式編碼？
Unicode規范中定義，每一個文件的最前面分別加入一個表示編碼順序的字符，這個字符的名字叫做”零寬度非換行空格“（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。這正好是兩個字節，而且FF比FE大1。
如果一個文本文件的頭兩個字節是FE FF，就表示該文件采用大頭方式；如果頭兩個字節是FF FE，就表示該文件采用小頭方式。
8. 實例
下面，舉一個實例。
打開”記事本“程序Notepad.exe，新建一個文本文件，內容就是一個”嚴“字，依次采用ANSI，Unicode，Unicode big endian 和 UTF-8編碼方式保存。
然后，用文本編輯軟件UltraEdit中的”十六進制功能“，觀察該文件的內部編碼方式。
1）ANSI：文件的編碼就是兩個字節“D1 CF”，這正是“嚴”的GB2312編碼，這也暗示GB2312是采用大頭方式存儲的。
2）Unicode：編碼是四個字節“FF FE 25 4E”，其中“FF FE”表明是小頭方式存儲，真正的編碼是4E25。
3）Unicode big endian：編碼是四個字節“FE FF 4E 25”，其中“FE FF”表明是大頭方式存儲。
4）UTF-8：編碼是六個字節“EF BB BF E4 B8 A5”，前三個字節“EF BB BF”表示這是UTF-8編碼，后三個“E4B8A5”就是“嚴”的具體編碼，它的存儲順序與編碼順序是一致的。
from：
http://blog.chinaunix.net/u2/76292/showart_1272892.html
]]>