java的代碼就不說了，畢竟不是我的主業(yè)。

1.c#數(shù)據(jù)庫連接池Hikari.

? ?(1)動(dòng)態(tài)加載各類數(shù)據(jù)庫驅(qū)動(dòng)

? （2）支持簡(jiǎn)單配置文件

（3）支持按照名稱多數(shù)據(jù)庫調(diào)用

（4）使用簡(jiǎn)潔

?單數(shù)據(jù)庫使用：

HikariConfig hikariConfig = new HikariConfig();
hikariConfig.LoadConfig("Hikari.txt");
HikariDataSource hikariDataSource = new HikariDataSource(hikariConfig);

獲取連接：

hikariDataSource.GetConnection();

連接池管理類獲取

ManagerPool.Instance.GetDbConnection(MySql);

項(xiàng)目地址：

https://github.com/jinyuttt/Hikari.git

2.c#數(shù)據(jù)庫封裝DBQuerySharp

（1）各類數(shù)據(jù)庫均有，功能齊備

（2）有SQL,NoSQL樣例，完善了封裝

（3）封裝成了服務(wù)化模型。擴(kuò)展使用和優(yōu)化

（4）有查詢的緩存優(yōu)化樣例。

整個(gè)包括了SQL數(shù)據(jù)庫(連接池任意配置)，本地KV數(shù)據(jù)庫(berkeleydb)，本地SQL數(shù)據(jù)庫(Sqlite)，內(nèi)存SQL數(shù)據(jù)庫(Sqlite)，內(nèi)存NOSQL數(shù)據(jù)庫(redis),內(nèi)存KV存儲(chǔ)（LRU緩存）

（5）相關(guān)項(xiàng)目

1.sqilte 2.berkeleydb 3.一般數(shù)據(jù)庫使用（通過Hikari） 4.redis ? 包含其他項(xiàng)目： 1.序列化 2.通信 3.自定義數(shù)據(jù)庫連接池

項(xiàng)目地址：

https://github.com/jinyuttt/DBQuerySharp.git

3.本地緩存JYCache

? (1)完全本地?fù)QK-V緩存

（2）實(shí)現(xiàn)FIFO,LRU,LFU策略

使用示例：

CacheConfig config = new CacheConfig();
config.CacheTime = 1800;//（時(shí)間都是秒)
config.Policy = CachePolicy.FIFO;//設(shè)置消失策略
ICache<int,int> cache=CacheFactory<int, int>.Create(config);
cache.CacheRemoveListener += Cache_CacheRemoveListener;
cache.Add(1, 1，10);//單獨(dú)設(shè)置key保持10秒

項(xiàng)目地址：

https://github.com/jinyuttt/JYCache.git

4.Hash一直負(fù)載均衡LoadBalanceHash

? (1)實(shí)現(xiàn)Hash一致算法。算法原理網(wǎng)上搜索很多，我就不說了。只需要搜索“Hash一致”

（2）這方面我不擅長(zhǎng)，主要是參閱網(wǎng)友的東西。我的封裝包括了2個(gè)項(xiàng)目。一個(gè)是網(wǎng)上原理KetamaHash .

? (3)主要參閱：https://www.cnblogs.com/daizhj/archive/2010/08/24/1807324.html；

? ? ? ? ? ? ? ? ? ? ? ??https://blog.csdn.net/cywosp/article/details/23397179/

?(4)代碼說明

?參考網(wǎng)上的代碼就不說了，一模一樣。主要是MD5+SortedList.

這里說我測(cè)試的另外一個(gè)組合。MurmurHash+SortedList.這個(gè)是充分驗(yàn)證了效率的。

MurmurHash算法比較快，網(wǎng)上多少M(fèi)D5.用法基本可以一樣，但是我沒有使用原來進(jìn)行分組了。底層存儲(chǔ)我測(cè)試了SortedDictionary,SortedList以及自定義紅黑樹（gi網(wǎng)友的，可以使用）。他們的主要問題都是在獲取Key右側(cè)最近的節(jié)點(diǎn)。都沒有提供現(xiàn)成的。所以測(cè)試很慢。

最后測(cè)試MurmurHash+SortedList.但是多了一層封裝。我將其SortedList與紅黑樹合并（也可以直接自己封裝一個(gè)類結(jié)構(gòu)，項(xiàng)目中也有樣例）。在初始化時(shí)，數(shù)據(jù)添加到紅黑樹中。然后通過UpdateSort快速遍歷，將數(shù)據(jù)導(dǎo)入SortedList存儲(chǔ)使用，這樣就啟用了其中為Hash一致封裝的功能TialNode.但是這里不能使用網(wǎng)上的方法，用linq查詢，太慢。我在內(nèi)部直接使用二分法進(jìn)行搜索。后面說原因。采用這種辦法會(huì)很快，而且直接返回最右側(cè)的一個(gè)值。這里強(qiáng)調(diào)一個(gè)問題，不能使用多線程分片查詢，更加慢。經(jīng)過測(cè)試，每個(gè)線程都是一樣的時(shí)間，和應(yīng)該線程直接查詢一樣的時(shí)間使用。都是很短的時(shí)間大約一個(gè)線程30-800（比毫秒還小的那個(gè)單位）。我測(cè)試使用的分片方法任然在，但是不能使用。這個(gè)可能和數(shù)據(jù)量有關(guān)，一個(gè)線程的數(shù)據(jù)量沒有千萬級(jí)就不要測(cè)試了，二分法的方法已經(jīng)夠快了，一次干掉一般的數(shù)據(jù)，沒有幾次就結(jié)束了。

最后說說碰上的一個(gè)小問題：比較SortedDictionary, SortedList。我推薦一篇文章，是我自己查閱源碼（net core）之后，認(rèn)為這篇文章是真實(shí)的。博文地址：https://blog.csdn.net/ma_jiang/article/details/78600043。我比較認(rèn)可。也正是由于2者的結(jié)構(gòu)，所以我最后采用SortedList來實(shí)現(xiàn)Hash一致。

? 關(guān)于這個(gè)問題說2點(diǎn)：SortedList內(nèi)存小，而且是線性數(shù)組實(shí)現(xiàn)的Key與value。SortedDictionary則是二叉樹。查詢一個(gè)是二分法，一個(gè)是二叉樹。另外一個(gè)困惑是，我采用紅黑樹搜索居然達(dá)不到它們2者的速度，我感覺奇怪。后面我再繼續(xù)測(cè)試吧。

項(xiàng)目地址：

https://github.com/jinyuttt/LoadBalanceHash.git

?

?

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/jinyu20180311/p/10386297.html

總結(jié)

以上是生活随笔為你收集整理的c#总结最近的几项重要代码的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。