跳到主要內容

Colder框架硬核更新（Sharding+IOC）

目錄



  • 引言

  • 控制反轉

  • 讀寫分離分庫分表

    • 理論基礎

    • 設計目標

    • 現狀調研

    • 設計思路

    • 實現之過五關斬六將

      • 動態對象

      • 動態模型緩存

      • 數據源移植

      • 查詢表達式樹深度移植

      • 數據合併算法

      • 事務支持


    • 實際使用


  • 展望未來


引言


前方硬核警告：全文乾貨11000+字，請耐心閱讀
遙想去年這個時候，差不多剛剛畢業，如今正式工作差不多一年了。Colder開源快速開發框架從上次版本發布至今差不多有三個月了，Github的星星5個版本框架總共也有近800顆，QQ群從最初的一個人發展到現在的500人（吐槽下，人數上限了，太窮開不起SVIP，所以另開了一個，群號在文章末），這都是大家共同發展的結果，本框架能夠幫助到大家鄙人就十分開心。但是，技術是不斷髮展的，本框架也必須適應潮流，不斷升級才能夠與時俱進，在實際意義上提高生產力。本系列框架從原始雛形（鄙人畢業設計）=>.NET45+Easyui=>.NET Core2.1+Easyui=>.NET45+AdminLTE=>.NET Core2.1+AdminLTE，這其中都是根據實際情況不斷升級。例如鄙人最初的畢業設計搭建了框架的雛形（倉儲層不夠完善、界面較簡陋），並不適合實際的生產開發，因此使用Easyui作為前端UI框架（控件豐富，使用簡單），后又由於.NET Core的發展迅速，已經發展到2.0，其基礎類庫組件也相對比較成熟了，因此從.NET45遷移到.NET Core。後來發現Easyui的樣式比較落後，給人一種過時古老的感覺，故而又將前端UI改為基於Bootstrap的AdminLTE，比較成熟主流並且開源。
但是，新的要求又出現了：



  • 由於沒有使用IOC導致各個類通過New導致的強耦合問題

  • 數據庫大數據量如何處理的問題
    因此，本次版本更新主要就是為了解決上述的問題，即全面使用Autofac作為IOC容器實現解耦以及數據庫讀寫分離分庫分表（Sharding）支持。下面將分別介紹。
    這次更新.NET45版本與.NET Core版本同步更新：






















.NET版本 前端UI 地址
Core2.2 AdminLTE https://github.com/Coldairarrow/Colder.Fx.Core.AdminLTE
.NET4.52 AdminLTE https://github.com/Coldairarrow/Colder.Fx.Net.AdminLTE

控制反轉


IOC（DI），即控制反轉（依賴注入），相關概念大家應該都知道，並且大多數人應該都已經運用於實際。我就簡單描述下，簡單講就是面向接口編程，通過接口來解除類之間的強耦合，方便開發維護測試。這個概念在JAVA開發中應該比較普遍，因為有Spring框架的正確引導，但是在.NET中可能開發人員的相關意識就沒那麼強，JAVA與.NET我這裏不做評價，但是作為技術人員，天生就是不斷學習的，好的東西當然要學習，畢竟技多不壓身。


在.NET 領域中IOC框架主流有兩個，即Autofac與Unity，這兩個都是優秀的開源框架，經過一番考量后我最終選擇了更加主流的（星星更多）Autofac。


關於Autofac的詳細使用教程請看官方文檔https://autofac.org/，我這裏主要介紹下集成到本框架的思路以及用法。
傳統使用方法通過手動註冊具體的類實現某接口，這種做法顯然不符合實際生產需求，需要一種自動註冊的方式。本框架通過定義兩個接口類：IDependency與ICircleDependency來作為依賴注入標記，所有需要使用IOC的類只需要繼承其中一個接口就好了，其中IDependency是普通注入標記，支持屬性注入但不支持循環依賴，ICircleDependency是循環依賴注入標記，支持循環依賴，實際使用中按需選擇即可。下面代碼就是自動註冊的實現：


var builder = new ContainerBuilder();
 
 var baseType = typeof(IDependency);
 var baseTypeCircle = typeof(ICircleDependency);
 
 //Coldairarrow相關程序集
 var assemblys = BuildManager.GetReferencedAssemblies().Cast<Assembly>()
     .Where(x => x.FullName.Contains("Coldairarrow")).ToList();
 
 //自動注入IDependency接口,支持AOP
 builder.RegisterAssemblyTypes(assemblys.ToArray())
     .Where(x => baseType.IsAssignableFrom(x) && x != baseType)
     .AsImplementedInterfaces()
     .PropertiesAutowired()
     .InstancePerLifetimeScope()
     .EnableInterfaceInterceptors()
     .InterceptedBy(typeof(Interceptor));
 
 //自動注入ICircleDependency接口,循環依賴注入,不支持AOP
 builder.RegisterAssemblyTypes(assemblys.ToArray())
     .Where(x => baseTypeCircle.IsAssignableFrom(x) && x != baseTypeCircle)
     .AsImplementedInterfaces()
     .PropertiesAutowired(PropertyWiringOptions.AllowCircularDependencies)
     .InstancePerLifetimeScope();
 
 //註冊Controller
 builder.RegisterControllers(assemblys.ToArray())
     .PropertiesAutowired();
 
 //註冊Filter
 builder.RegisterFilterProvider();
 
 //註冊View
 builder.RegisterSource(new ViewRegistrationSource());
 
 //AOP
 builder.RegisterType<Interceptor>();
 
 var container = builder.Build();
 DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
 
 AutofacHelper.Container = container;

代碼中有相關註釋，使用方法推薦使用構造函數注入：

框架已在Business層與Web層全面使用DI，Util層、DataRepository層與Entity層不涉及業務邏輯，因此不使用DI。


讀寫分離分庫分表


前面的IOC或許沒啥可驚喜的，但是數據庫讀寫分離分庫分表應該不會讓大家失望。接下來將闡述下框架支持Sharding的設計思路以及具體使用方法。


理論基礎


數據庫讀寫分離分庫分表（以下簡稱Sharding），這並不是什麼新概念，網上也有許多的相關資料。其根本就是為了解決一個問題，即數據庫大數據量如何處理的問題。


當業務規模較小時，使用一個數據庫即可滿足，但是當業務規模不斷擴大（數據量增大、用戶數增多），數據庫最終將會成為瓶頸（響應慢）。數據庫瓶頸主要有三種情況：數據量不大但是讀寫頻繁、數據量大但是讀寫不頻繁以及數據量大並且讀寫頻繁。


首先，為了解決數據量不大但是讀寫頻繁導致的瓶頸，需要使用讀寫分離，所謂讀寫分離就是將單一的數據庫分為多個數據庫，一些數據庫作為寫庫（主庫），一些數據庫作為讀庫（從庫），並且開啟主從複製（實時將寫入的數據同步到從庫中），這樣將數據的讀寫分離后，將原來單一數據庫用戶的讀寫操作分散到多個數據庫中，極大的降低了數據庫壓力，並且打多數情況下讀操作要遠多於寫操作，因此實際運用中大多使用一主多從的模式。


其次，為了解決數據量大但是讀寫不頻繁導致的瓶頸，需要使用分庫分表。其實思想也是一樣的，即分而治之，一切複雜系統都是通過合理的拆分從而有效的解決問題。分庫分表就是將原來的單一數據庫拆分為多個數據庫，將原來的一張表拆分為多張表，這樣表的數據量就將下來了，從而解決問題。但是，拆表並不是胡亂拆的，隨便拆到時候數據都找不到，那還怎麼玩，因此拆表需要按照一定的規則來進行。最簡單的拆表規則，就是根據Id字段Hash后求余，這種方式使用簡單但是擴容很麻煩（絕大多數都需要遷移，工作量巨大，十分麻煩），因此大多用於基本無需擴容的業務場景。後來經過一番研究后，發現可以使用雪花Id（分佈式自增Id）來解決問題，雪花Id中自帶了時間軸，因此在擴容時可以根據時間段來判斷具體的分片規則，從而擴容時無需數據遷移，但是存在一定程度上的數據熱點問題。最後，找到了葵花寶典-一致性哈希，關於一致性哈希的理論我這裏就不獻醜了，相關資料網上一大把。一致性哈希從一定程度上解決了普通哈希的擴容問題與數據熱點問題，框架也支持使用一致性哈希分片規則。


最後，就是大BOSS，大數據量與大訪問量，很簡單隻需要結合讀寫分離與分庫分表即可，下錶是具體業務場景與採用方案的關係
| 數據量\訪問量 | 小 | 大 |
|-|-|-|
|小| 無| 讀寫分離 |
| 大 | 分庫分表 |讀寫分離分庫分表|


設計目標


首先定一個小目標（先賺他一個億）：支持多種數據庫，使用簡單，業務升級改動小。
有了目標就需要調查業界情況，實現Sharding，市面上主要分為兩種，即使用中間件與客戶端實現。


現狀調研


中間件的優點是對客戶端透明，即對於客戶端來講中間件就是數據庫，因此對於業務改動影響幾乎沒有，但是對中間件的要求就很高，目前市面上比較主流成熟的就是mycat，其對MySQL支持比較好，但是對於其他數據庫支持就比較無力（個人測試，沒有深入研究，若有不妥請不要糾結），並且不支持EF，此方案行不通。其它類型數據庫也有對應的中間件，但是都並不如意，自己開發更不現實，因此使用中間件方案行不通。


既然中間件行不通，那就只能選擇客戶端方案了。目前在JAVA中有大名鼎鼎的Sharding-JDBC，了解了下貌似很牛逼，可惜.NET中並沒有Sharding-NET，但是有FreeSql，粗略了解了下是一個比較強大ORM框架，但我的框架原來底層是使用EF的，並且EF是.NET中主流的ORM框架，整體遷移到FreeSql不現實，因此最終沒找到成熟的解決方案。


設計思路


最後終於到了最壞的情況，既沒有完美的中間件方案，又沒有現成的客戶端方案，怎麼辦呢？放棄是不可能的，這輩子都不可能放棄的，終於，內心受到了黨的啟發，決定另起爐灶（既然沒有現成的那就自己早造）、打掃乾淨屋子再請客（重構數據倉儲層，實現Sharding）、一邊倒（堅定目標不改變，不妥協），由於EF支持多種數據庫，已經對底層SQL進行了抽象封裝，因此決定基於EF打造一套讀寫分離分庫分表方案。


數據庫讀寫分離實現：讀寫分離比較簡單，在倉儲接口中已經明確定義了CRUD操作接口，其中增、刪、改就是指寫操作，寫的時候按照具體的讀寫規則找到具體的寫庫進行寫操作即可，讀操作（查數據）按照具體的讀規則找到具體的讀庫進行讀即可。


數據庫分庫分表：分庫還好說，使用不同的數據庫即可，分表就比較麻煩了。首先實現分表的寫操作，可以根據分片規則能夠找到具體的物理表然後進行操作即可，實現比較容易。然後實現分表的讀操作，這個就比較麻煩了，就好比前面的都是斗皇以下的在小打小鬧，而這個卻是斗帝（騎馬），但是，作為一名合格的攻城獅是不怕斗帝的，遇到了困難不要慌，需要冷靜思考處理。前面提到過，解決複雜問題就是一個字"拆"，首先聯表查詢就直接不考慮支持了（大數據量進行笛卡爾積就是一種愚蠢的做法，怎麼優化都沒用，物理數據庫隔絕聯表不現實，實現難度太大放棄）。接下來考慮最常用的方法：分頁查詢、數據篩選、最大值、最小值、平均值、數據量統計，EF中查詢都是通過IQueryable接口實現的，IQueryable中主要包括了數據源（特定表）與關聯的表達式樹Expression，通過考慮將數據源與關聯的表達式樹移植到分表的IQueryable即可實現與抽象表相同的查詢語句，最後將併發多線程查詢分表的數據通過合併算法即可得到最終的實際數據。想法很美好，現實很殘酷，下面為大家簡單闡述下實現過程，可以說是過五關斬六將。


實現之過五關斬六將


動態對象


首先考慮分表的寫操作，傳統用法都有具體的實體類型進行操作，但是分表時，例如Base_UnitTest_0、Base_UnitTest_1、Base_UnitTest_2，這些表全部保存為實體類不現實，因此需要一種非泛型方法，後來在EF的關鍵類DbContext中找到DbEntityEntry Entry(object entity)方法，通過DbEntityEntry可以實現數據的增刪改操作，又注意到傳入參數是object，由此猜測EF支持非泛型操作，即只需要傳入特定類型的object對象也行。例如抽象表是Base_UnitTest，實際需要映射到表Base_UnitTest_0，那麼怎樣將Base_UnitTest類型的對象轉換成Base_UnitTest_0類型的對象？經過查閱資料，可以通過System.Reflection.Emit命名空間下的TypeBuilder在運行時創建動態類型，即可以在運行時創建Base_UnitTest_0類型，該類型擁有與Base_UnitTest完全一樣的屬性（因為表結構完全一樣），創建了需要的類型，接下來只需要通過Json.NET將Base_UnitTest對象轉為Base_UnitTest_0即可。實現到這裏，原以為會順利成功，但是並沒有那麼簡單，EF直接報錯"上下文不包含模型Base_UnitTest_0"，這明顯就是模型的問題了，接下來進入下一關：EF動態模型緩存


動態模型緩存


通常都是通過繼承DbContext重寫OnModelCreating方法來註冊實體模型，這裡有個坑就是OnModelCreating只會執行一次，並最終生成DbCompiledModel然後將其緩存，後續創建的DbContext就會直接使用緩存的DbCompiledModel，由於最初註冊實體模型的時候只有抽象類型Base_UnitTest，所有後續在使用Base_UnitTest_0對象的時候會報錯。為了解決這個問題，需要自己管理DbCompiledModel緩存，實現過程比較麻煩，這裏就不詳細分析了，有興趣的直接看源碼即可。將緩存問題解決后，終於成功的實現了Base_UnitTest_0的增刪改，這時，心裏一喜（有戲）。實現了寫操作（增、刪、改）之後，接下來就是實現查詢了，那麼如何實現查詢呢？EF中查詢操作都是通過IQueryable接口實現的，IQueryable中包括了具體數據表的數據源和關聯的查詢表達式樹，那麼如何將IQueryable < Base_UnitTest >轉換為IQueryable < Base_UnitTest_0 > 並且保留原始查詢語句就成了關鍵問題。


數據源移植


根據經驗，想一舉同時移植數據源與表達式樹應該不現實，實際情況也是如此，移植數據源，通過使用ExpressionVisitor可以找到根數據源，其實是一個ObjectQuery類型，並且在表達式樹中是以ConstantExpression存在，同樣通過ExpressionVisitor則可將原ObjectQuery替換為新的，實現過程省略10000字。


查詢表達式樹深度移植


數據源移植后，別以為就大功告成了，接下來進入一個深坑（最難點），表達式樹移植，經過一番踩坑后發現，表達式樹中的所有節點都是樹狀結構，任何一個查詢（Where、OrderBy、Skip、Take等）在表達式樹中都是以一個節點存在，並且一級扣一級，也就是說你改了數據源沒用，因為數據源只是表達式樹的根節點，下面的所有子節點還都是原來的根節點發的牙，並不能使用，那怎樣才能用新數據源構建與原數據源一樣的表達式樹呢？經過如下分析：IQuryable中的所有操作都是MethodCallExpression一層一層包裹，那麼我從外到內剝開方法，然後再從內到外包裹新的數據源，那不就模擬得一模一樣了嗎？（貌似有戲），想到先進后出腦子里直接就蹦出了數據結構中的棧，強大的.NET當然支持棧了，經過一番操作（奮鬥幾個晚上），此處省略10000字，最終完成IQueryable的移植，即從IQueryable < Base_UnitTest >轉換為IQueryable < Base_UnitTest_0 > 並且保留原始查詢語句。有了分表的IQueryable就能夠獲取分表的數據了，最後需要將獲取的分表數據進行合併。


數據合併算法


分表后的數據合併算法主要參考了網上的一些資料，雖然分庫分表的實現方式各不相同，但是思想都是差不多的，例如需要獲取Count，只需要將各個分表的Count求和即可，最大值只需要所有分表的最大值的最大值即可，最小值只需要所有分表最小值的最小值即可，平均值需要所有分表的和然後除以所有分表的數據條數即可。最後比較麻煩的就是分頁查詢，分頁查詢需要分表排序后獲取前N頁的所有數據（不能直接獲取某一頁的數據，因為不一定就是那一頁），最後將所有表的數據再進行分頁即可。實現到這裏，已經實現了增、刪、改、查了，看似革命已經成功，其實還有最後的大BOSS：事務支持


事務支持


因為分表很可能不在同一個數據庫中，因為普通的單庫事務顯然不能滿足需求，原本框架中已經有分佈式事務支持（多庫事務），這裏需要集成到Sharding中，實現過程省略10000字，最終黃天不負有心人終於實現了。


到這裏，肯定有暴躁老哥坐不住了：你前面BBB那麼多，說得那麼牛逼，到底怎麼用啊？？？，若文章到此為止，估計就是下圖：



鄙人則回復如下：



深夜12點了，放鬆一下，最後介紹如何使用


實際使用


本框架支持數據庫讀寫分離分庫分表（即Sharding），並且支持主流關係型數據庫（SQLServer、Oracle、MySQL、PostgreSQL）,理論上只要EF支持那麼本框架支持。
由於技術原因以及結合實際情況，目前本框架僅支持單表的Sharding，即支持單表的CRUD、分頁、統計（數量、最大值、最小值、平均值），支持跨庫（表分散在不同的數據庫中，不同類型數據庫也支持）。具體如何使用如下：



  • Sharding配置
    首先、要進行分庫分表操作，那麼必要的配置必不可少。配置代碼如下：


ShardingConfigBootstrapper.Bootstrap()
     //添加數據源
     .AddDataSource("BaseDb", DatabaseType.SqlServer, dbBuilder =>
     {
         //添加物理數據庫
         dbBuilder.AddPhsicDb("BaseDb", ReadWriteType.ReadAndWrite);
     })
     //添加抽象數據庫
     .AddAbsDb("BaseDb", absTableBuilder =>
     {
         //添加抽象數據表
         absTableBuilder.AddAbsTable("Base_UnitTest", tableBuilder =>
         {
             //添加物理數據表
             tableBuilder.AddPhsicTable("Base_UnitTest_0", "BaseDb");
             tableBuilder.AddPhsicTable("Base_UnitTest_1", "BaseDb");
             tableBuilder.AddPhsicTable("Base_UnitTest_2", "BaseDb");
         }, new ModShardingRule("Base_UnitTest", "Id", 3));
     });

上述代碼中完成了Sharding的配置：
ShardingConfigBootstrapper.Bootstrap()在一個項目中只能執行一次，所以建議放到Application_Start中（ASP.NET Core中的Startup）
AddDataSource是指添加數據源，數據源可以看做抽象數據庫，一個數據源包含了一組同類型的物理數據庫，即實際的數據庫。一個數據源至少包含一個物理數據庫，多個物理數據庫需要開啟主從複製或主主複製，通過ReadWriteType（寫、讀、寫和讀）參數來指定數據庫的操作類型，通常將寫庫作為主庫，讀庫作為從庫。同一個數據源中的物理數據庫類型相同，表結構也相同。
配置好數據源后就可以通過AddAbsDb來添加抽象數據庫，抽象數據庫中需要添加抽象數據表。如上抽象表Base_UnitTest對應的物理表就是Base_UnitTest_0、Base_UnitTest_1與Base_UnitTest_2，並且這三張表都屬於數據源BaseDb。分表配置當然需要分表規則（即通過一種規則找到具體數據在哪張表中）。
上述代碼中使用了最簡單的取模分片規則，
源碼如下：

可以看到其使用方式及優缺點。
另外還有一致性HASH分片規則

雪花Id的mod分片規則


上述的分片規則各有優劣，都實現IShardingRule接口，實際上只需要實現FindTable方法即可實現自定義分片規則。
實際使用中個人推薦使用雪花Id的mod分片規，這也是為什麼前面數據庫設計規範中默認使用雪花Id作為數據庫主鍵的原因（PS，之前版本使用GUID作為主鍵被各種嫌棄，這次看你們怎麼說）



  • 使用方式
    配置完成，下面開始使用，使用方式非常簡單，與平常使用基本一致
    首先獲取分片倉儲接口IShardingRepository


IShardingRepository _db = DbFactory.GetRepository().ToSharding();

然後即可進行數據操作：


Base_UnitTest _newData  = new Base_UnitTest
 {
     Id = Guid.NewGuid().ToString(),
     UserId = "Admin",
     UserName = "超級管理員",
     Age = 22
 };
 List<Base_UnitTest> _insertList = new List<Base_UnitTest>
 {
     new Base_UnitTest
     {
         Id = Guid.NewGuid().ToString(),
         UserId = "Admin1",
         UserName = "超級管理員1",
         Age = 22
     },
     new Base_UnitTest
     {
         Id = Guid.NewGuid().ToString(),
         UserId = "Admin2",
         UserName = "超級管理員2",
         Age = 22
     }
 };
 //添加單條數據
 _db.Insert(_newData);
 //添加多條數據
 _db.Insert(_insertList);
 //清空表
 _db.DeleteAll<Base_UnitTest>();
 //刪除單條數據
 _db.Delete(_newData);
 //刪除多條數據
 _db.Delete(_insertList);
 //刪除指定數據
 _db.Delete<Base_UnitTest>(x => x.UserId == "Admin2");
 //更新單條數據
 _db.Update(_newData);
 //更新多條數據
 _db.Update(_insertList);
 //更新單條數據指定屬性
 _db.UpdateAny(_newData, new List<string> { "UserName", "Age" });
 //更新多條數據指定屬性
 _db.UpdateAny(_insertList, new List<string> { "UserName", "Age" });
 //更新指定條件數據
 _db.UpdateWhere<Base_UnitTest>(x => x.UserId == "Admin", x =>
 {
     x.UserId = "Admin2";
 });
 //GetList獲取表的所有數據
 var list=_db.GetList<Base_UnitTest>();
 //GetIQPagination獲取分頁后的數據
 var list=_db.GetIShardingQueryable<Base_UnitTest>().GetPagination(pagination);
 //Max
 var max=_db.GetIShardingQueryable<Base_UnitTest>().Max(x => x.Age);
 //Min
 var min=_db.GetIShardingQueryable<Base_UnitTest>().Min(x => x.Age);
 //Average
 var min=_db.GetIShardingQueryable<Base_UnitTest>().Average(x => x.Age);
 //Count
 var min=_db.GetIShardingQueryable<Base_UnitTest>().Count();
 //事務,使用方式與普通事務一致
 using (var transaction = _db.BeginTransaction())
 {
     _db.Insert(_newData);
     var newData2 = _newData.DeepClone();
     _db.Insert(newData2);
     bool succcess = _db.EndTransaction().Success;
 }

上述操作中表面上是操作Base_UnitTest表，實際上卻在按照一定規則使用Base_UnitTest_0~2三張表，使分片對業務操作透明，極大提高開發效率，基本達成了最初定製的小目標。
具體使用方式請參考單元測試源碼：
"\src\Coldairarrow.UnitTests\DataRepository\ShardingTest.cs"


最後放上簡單的測試圖：300W的表分成三張100W的表後效果


看來功夫沒白費，效果明顯（還不快點贊）


展望未來


結束也是是新的開始，版本後續計劃採用前後端完全分離方案，前端使用vue-element-admin，後端以.NET Core為主，傳統的.NET將逐步停止更新，敬請期待！
文章雖然結束了，但是技術永無止境，希望我的文檔能夠幫助到大家。
深夜碼字，實屬不易，文章中難免會出現一些紕漏，一些觀點也不一定完全正確，還望各位大哥不吝賜教。
最後覺得文檔不錯，請點贊，Github請星星，若有各種疑問歡迎進群交流：
QQ群1:373144077（已滿）
QQ群2:579202910



See You

【精選推薦文章】



智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選



想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計



帶您來看台北網站建置，台北網頁設計，各種案例分享



廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益


Orignal From: Colder框架硬核更新（Sharding+IOC）

留言

張貼留言

這個網誌中的熱門文章

Python 併發總結，多線程，多進程，異步IO

1 測量函數運行時間 import time def profile(func): def wrapper(*args, ** kwargs): import time start = time.time() func( *args, ** kwargs) end = time.time() print ' COST: {} ' .format(end - start) return wrapper @profile def fib(n): if n<= 2 : return 1 return fib(n-1) + fib(n-2 ) fib( 35 )   2 啟動多個線程，並等待完成   2.1 使用threading.enumerate() import threading for i in range(2 ): t = threading.Thread(target=fib, args=(35 ,)) t.start() main_thread = threading.currentThread() for t in threading.enumerate(): if t is main_thread: continue t.join()   2.2 先保存啟動的線程 threads = [] for i in range(5 ): t = Thread(target=foo, args= (i,)) threads.append(t) t.start() for t in threads: t.join()   3 使用信號量，限制同時能有幾個線程訪問臨界區 from threading import Semaphore import time sema = Semaphor...
張貼留言
閱讀完整內容

韋伯連續劇終於更新 期待第一季順利完結

　　地球天文學界的跳票大王詹姆斯·韋伯空間望遠鏡 (James Webb Space Telescope，縮寫為 JWST)自 1996 年以來斷斷續續不按劇本演出的連續劇終於讓焦慮的觀眾們又等到了一次更新：五層遮陽罩測試順利完成。 裝配完成的韋伯望遠鏡與好夥伴遮陽罩同框啦。Credit: NASA 　　嚴格的測試是任何空間任務順利成功的重中之重。遮陽罩，這個韋伯望遠鏡異常重要的親密夥伴，要是無法正常運轉的話，韋伯的這一季天文界連續劇說不準就要一直拖更了。 　　詹姆斯·韋伯空間望遠鏡是歷史上造出的最先進的空間望遠鏡。它不僅是一架紅外望遠鏡，還具有特別高的靈敏度。但想要達到辣么高的靈敏度來研究系外行星和遙遠的宇宙童年，韋伯童鞋必須非常"冷靜"，體溫升高的話，靈敏度會大大折損。這個時候，遮陽罩就要大顯身手啦。 　　遮陽罩在韋伯的設計中至關重要。韋伯望遠鏡會被發射到拉格朗日 L2 點，運行軌道很高，遠離太陽、地球與月球。太陽是韋伯的主要熱量干擾的來源，其次是地球與月球。遮陽罩會有效阻斷來自這三大熱源的能量並保護韋伯維持在工作溫度正常運轉。這個工作溫度指的是零下 220 攝氏度(-370 華氏度；50 開爾文)。 上圖中我們可以看出，韋伯望遠鏡的配置大致可分為兩部分：紅色較熱的一面溫度為 85 攝氏度，藍色較冷的一面溫度達到零下 233 攝氏度。紅色的這部分中，儀器包括太陽能板、通信設備、計算機、以及轉向裝置。藍色部分的主要裝置包括鏡面、探測器、濾光片等。Credit: STSci. 　　遮陽罩的那一部分和望遠鏡的鏡面這部分可以產生非常極端的溫差。遮陽的這面溫度可以達到 110 攝氏度，足以煮熟雞蛋，而背陰處的部分溫度極低，足以凍結氧氣。 　　工程師們剛剛完成了五層遮陽罩的測試，按照韋伯在 L2 時的運行狀態安裝了遮陽罩。L2 距離地球約 160 萬公里。NASA 表示這些測試使用了航天器的自帶系統來展開遮陽罩，測試目前都已成功完成。韋伯望遠鏡遮陽罩負責人 James Cooper 介紹說這是遮陽罩"第一次在望遠鏡系統的电子設備的控制下展開。儘管這個任務非常艱巨，難度高，但測試順利完成，遮陽罩展開時的狀態非常驚艷"。 　　遮陽罩由五層 Kapton 製成。Kapton 是一種聚酰亞胺薄膜材料， 耐高溫絕...
張貼留言
閱讀完整內容

LINE 發票管家「一鍵分享發票」新功能，聚餐AA更好算帳

» » LINE 發票管家「一鍵分享發票」新功能，聚餐AA更好算帳 消費明細好清楚，不怕算錯錢啦！ by in , 讀取中... 之前介紹過的「LINE 發票管家」，除了能對統一發票、管理消費紀錄，現在還能分享消費明細給其他朋友囉！趕快來看看該如何分享吧！讓大家在聚餐過後，不用再截圖、拍照把消費明細記錄下來分享到 LINE 好友群組，只要用 LINE發票管家就可以隨時一鍵分享消費明細，包括店家、消費時間、消費項目、金額通通都有，聚餐 AA 也更好算帳。 LINE 發票管家「一鍵分享發票」新功能，聚餐AA更好算帳 朋友聚餐完，經常會先由其中一位買單再事後收帳，不過難免擔心忘記拍照紀錄下消費明細，導致算帳變得很麻煩。但是，現在只要用 LINE發票管家，不僅能將發票存入載具後直接匯入發票，進而更方便管理每月的消費情況，現在還能用它來分享消費明細到 LINE 聊天室，不需要截圖，整個流程超級簡單！ ▲圖片來源： 當使用 LINE發票管家並且綁定載具後，只要日常消費有將發票存入載具就通通會自動匯入 LINE發票管家。如果想暸解自己近期的消費情況，也能在 LINE發票管家點選「發票明細」查詢所有消費紀錄。 ＊小提醒：存入手機條碼的發票，待財政部 1-2 日作業時間將發票資料匯入後， 打開單筆消費後分享到指定對象或群組。 像是朋友聚餐或其它購物消費，就能在 LINE發票管家查看每一筆消費的所有消費明細，每一項餐點的項目、價格通通一目了然。如果想將該筆消費內容分享給好友收帳，只要點選該筆消費明細後，接著點選畫面右上角的「分享」按鈕。 網頁設計 最專業,超強功能平台可客製,窩窩以「數位行銷」「品牌經營」「網站與應用程式」「印刷品設計」等四大主軸，為每一位客戶客製建立行銷脈絡及洞燭市場先機,請問 台中電動車 哪裡在賣比較便宜可以到台中景泰電動車門市去看看總店：臺中市潭子區潭秀里雅潭路一段102-1號。 電動車補助 推薦評價好的 iphone維修 中心擁有專業的維修技術團隊，同時聘請資深iphone手機維修專家，現場說明手機問題，快速修理，沒修好不收錢住家的頂樓裝 太陽光電 聽說可發揮隔熱功效一線推薦東陽能源擁有核心技術、...
張貼留言
閱讀完整內容