話題討論：大規(guī)模高并發(fā)下的分布式存儲架構(gòu)設(shè)計

田野

關(guān)于accessToken的存儲方式？
存儲到數(shù)據(jù)庫
存儲到session/cookie
存儲到具體的文件中
個人能想到的就這三種方式，然后哪種使用更佳？

記得喝水

活動啥時候結(jié)束

chunshui

訂單分表存儲？有幾個問題請教一下各位大神，謝謝
1、如果對訂單表進(jìn)行分表存儲呢？按人，還是按日期，或者其他？
2、如果分表查詢，那如何查詢所有時，連表查詢？

socall

redis作為緩存的特性有很多好處,可以緩解服務(wù)器壓力
先判斷緩存中有沒有，沒有的話查DB
有的話直接使用
那如果DB更新了呢？redis中的數(shù)據(jù)不就是舊的臟數(shù)據(jù)了嗎？

THUNDER2

求推薦分布式方案

kikiv

用rest http相當(dāng)于再寫一個接口，所有接口都需要修改也有點(diǎn)麻煩，

有其他更好的方案么？或者框架？

matador

分布式架構(gòu)中，一個web調(diào)用多個服務(wù)，怎么樣保證事務(wù)。就是多個服務(wù)在不同的服務(wù)器上面，怎么保證事務(wù)？

zzzhangyi

求WCF 分布式 事務(wù)例子
一個星期了
怎么樣都不會RollBack
求例子(最好能打包下載的)+詳細(xì)配置

nike_hao

首先HBase是列式存儲，也就是說在一個HFILE（Storefile）中存放著一個列族，在HFILE大小達(dá)到閾值后會觸發(fā)split操作將原Region下線分裂成兩個等同的region并取其一發(fā)送到新的regionserver，這個理解應(yīng)該是正確的吧？
然而很明顯，一個列族中，不同的列根據(jù)數(shù)據(jù)類型不同，所占空間大小也一樣，比如cf：a中存放int，一個值只占1K（假設(shè)，大小不要在意）而cf：b中存放bigint，一個值占1M（還是假設(shè)）而cf2：c中存放string，一個值占10M，而HFILE則是以大小為標(biāo)準(zhǔn)而非條目數(shù)為標(biāo)準(zhǔn)，所以每個HFILE中存儲的條目數(shù)勢必是不相等的
那么同一個datanode中的HFILE，可能存儲了cf：a到100w列，而cf：b則存到了第50w列，cf2：c中則僅存儲了10w列就存完了（請不要在意條目數(shù)與HFILE分裂閾值的關(guān)系，這里的數(shù)值為了讓差距明顯而刻意改變）
這時我的問題來了：當(dāng)我需要第90000列進(jìn)行cf:a+cf:b+cf2:c運(yùn)算的時候，cf：a的第9w列在datanode1上，cf：b的第9w列在datanode2上，而cf2：c的第9w列在datanode3上。
這時HBASE會通過網(wǎng)絡(luò)傳輸這些列到任意機(jī)器上嗎？
上面只是一個數(shù)據(jù)量極小的假設(shè)，那么將數(shù)據(jù)量同步擴(kuò)大
我需要批量計算共計10w列的cf：a+cf：b+cf2：c運(yùn)算，而這10w列很可能將分布在不同的datanode中，這時會造成網(wǎng)絡(luò)堵塞嗎？（或者最起碼，要把這些數(shù)據(jù)讀出來進(jìn)行網(wǎng)絡(luò)傳輸，總要進(jìn)行IO吧）
而HBASE是一個基于大量數(shù)據(jù)的數(shù)據(jù)庫，在進(jìn)行大量數(shù)據(jù)計算時先要進(jìn)行大量的網(wǎng)絡(luò)數(shù)據(jù)重新傳輸然后再計算，這個結(jié)論顯然是不對的
請問我哪里理解錯誤了呢？
求大神解答

nike_hao

redis使用setnx命令創(chuàng)建鎖,失效時間我設(shè)置多長時間為好？如何設(shè)置的失效時間太短，方法沒等執(zhí)行完，鎖就自動釋放了，那么就會產(chǎn)生并發(fā)問題。如果設(shè)置的時間太長，其他獲取鎖的線程就可能要平白的多等一段時間。在只考慮單機(jī)redis的情況下,如何處理這個問題?