愛說說技術原理方案的定選思考過程(一)

今天把“愛說說”的起源及技術方案的選型過程及想法給大夥說說

說白了也沒什麼什麼，可以說是微網誌、閃存、聊天室，什麼都可以說。

說要寫“愛說說”，最直白的沖動是在部落格園閃存閃多了，突然也閃出這麼個名詞，是以打算随意的折騰一下，于是就出來了。

1：回想往惜做過類似的：

1：在校的時候學習，都學着用Application來存聊天室的内容。

2：剛工作的時候，學到了記憶體表DataTable來存聊天室的内容。

3：工作有點久的時候，寫一個webim[設計人員設計了和msn一樣的界面]，同樣有群的功能，技術方案是記憶體表DataTable+資料庫存儲的方案。

部落格園的閃存技術方案：

猜的：也許可能大概：是利用json+webservice+資料庫的方案

2：愛說說的技術方案：

秋色園愛說說的技術方案[開始的方案]：

随着秋色園的向前優化，CYQ.Data不斷的更新，MDataTable不斷的優化。

于是很容易定位了一下愛說說的技術方案：

記憶體表MDataTable+XML

理由：

沒什麼特别，因為最近給CYQ.Data的MDataTable增加了WriteXml和ReadXml功能，

想着剛好能應用上。

秋色園愛說說的技術方案[現在的方案]：

在秋式開源團隊裡說了一下技術方案，有人不小說到了文本這個詞，讓我想起了另一種方案：記憶體表MDataTable+json+TXT

CYQ.Data.Table下的MDataTable對Json的支援是比較穩定的，剛好可以優化及增加一下其它功能，比如說MDataTable的Select功能。

再者不成熟的想了一下，秋色園用Access，二級域名不也能太進階，用TXT比較有創意一些。

3：方案的說法

用TXT文本來來當存儲媒體，這是一個比較有創意的想法，當然有很多人似乎要否定TXT，甚者有人說：“從前，有個PHP的論壇，用的是TXT做為資料庫，後來它消失了”。

如果讓我做論壇，我也不會選TXT做為存儲媒體，原因當然是論壇和“愛說說”是不一樣的。

愛說說本身并沒有多複雜的邏輯，也不會并生多大的資料量，說什麼微網誌資料量大，你不是新浪騰訊或是搜狐的，瞎扯上這麼進階别的資料量了，不現實，

再說資料量這麼大，肯定是有米的，有米的都喜歡自己寫一套的，寫多幾套也不是問題。

事實上，我看了一下部落格園，平均一天就閃1000條，我用TXT測試到1萬條，讀取仍然很快。

是以完全不用擔心，上升到2萬3萬10萬呢，你說呢？

4：為啥不用Sqlite，好多人說用這個

簡單想了一下，當初秋色園Access才并發了幾十個寫操作，就挂了，[大石頭]傳說[Access25個并發最多],SQLite在寫這方面，也不太樂觀，是以不考慮，為啥不考慮？

一開始的考慮本意是這樣的：使用者說過來的消息，然後集中到記憶體中，再定時的寫資料。

後來想了想，不靠譜，因為記憶體回收是常有的事，不是資料得經常性的丢麼，說句有的沒的，大夥說的也沒勁。

是以資料還是需要時時寫的，是以用這種小型資料庫沒法支援這麼大的并發寫資料問題，是以，好像大夥都懂了。

于是用TXT文本，用Ajax循環發送1000條請求寫資料，發現很安穩，安心了。

5：用TXT肯定是會遇到一些技術問題的

這些技術問題，這本不說先，下一篇為大夥解析，歡迎大夥留言愛說說。

1：需要前端再設計，目前的界面是我瞎折騰的，不太成型，重新設計是必然。

2：JS前端，本人JS能力不及，相容不了多浏覽器，待再找個高手重寫一下。

3：咋不用JQ?好多人問我：一是JQ的包大了點，二是比較重要的，我不會JQ，汗一個。

4：功能：還少很多，比如注冊使用者，及相關的查詢，按日期的顯示，“更多”的查詢等。

5：目前js寫的比較差，有時候會卡，這個得趕緊優化下。

最後本節就先寫到這了，歡迎大夥亂彈彈。

     本文轉自cyq1162 51CTO部落格，原文連結：http://blog.51cto.com/cyq1162/595589

，如需轉載請自行聯系原作者