整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
一、打印機連接的電腦開啟打印機共享。
1、把打印機連接到電腦，下載并安裝打印機驅動，確保打印機可以正常使用。
2、查看網絡連接，確保網絡配置為專用網絡（關鍵）
專用網絡
3、打開網絡共享，確保當前配置為專用網絡（來賓或公用網絡不支持）
4、按窗口+R鍵，打開運行，輸入secpol.msc，打開配置策略窗口，設置兩個位置。
一是在安全選項中，查看右邊窗口配置項，檢查guest來賓賬戶是否禁用，如果禁用則將其啟用。如圖所示：
二是在用戶權限分配中，查看右邊窗口配置項“拒絕從網絡訪問這臺計算機”，雙擊打開，講guest刪除，允許來賓賬戶從網絡訪問。
5、打開設置—>設備—>打印機和掃描儀，點擊需要共享的打印機，點擊管理—>打印機屬性，配置兩個位置，一個是共享標簽頁，點擊“更改共享選項”，然后勾選“共享這臺打印機”。
另外一個是點擊安全標簽頁，確保的打印權限是“允許”。
打印機共享端配置完畢。
二、其他電腦連接配置
1、確保其他電腦的網絡連接當前配置為專用網絡（必須）
2、打開設置—>設備—>打印機和掃描儀，點擊“添加打印機和掃描儀”。
3、如果檢索到，直接點擊檢索到的你需要安裝的打印機和掃描儀，如果沒有檢索到，點擊“我需要的打印機不在列表中”。
在彈出的手動添加打印機對話框中，可以根據時機需要選擇添加的方式，針對本文配置如下圖所示，手動輸入打印機連接的那臺電腦的ip地址。
一般情況下，可以配置完畢。
本文針對的是win10共享打印機，win10連接的問題，如果是win10共享，win7或者xp連接請看其他文章。
【技術分享】分布式架構中的時間真相
感謝業界小伙伴——吳松林，投稿精品原創類文章。VSRC歡迎精品原創類文章投稿，優秀文章一旦采納發布，將有好禮相送，我們已為您準備好了豐富的獎品！
（活動最終解釋權歸VSRC所有）
分布式架構中的時間真相
對于生活中常見的事物，我們總是缺乏細心的觀察與足夠的思考。作者將在這篇文章中帶領大家深入分布式架構中時間的真相。本文不打算使用過于專業的術語和晦澀難懂的數學公式，希望能和同學們輕松愉快的展開討論。
我們所熟知的時間
時間是人類用以描述物質運動過程或事件發生過程的一個參數。確定時間的方法通常是靠不受外界影響的物質周期變化的規律，例如月亮繞地球旋轉周期，原子震蕩周期等。
以上是基本物理學中對于時間的定義，也是我們生活中對于時間的主要感受。
能不能稍微高大上一點？
愛因斯坦在相對論中提出：不能把時間、空間、物質三者分開解釋。時間與空間一起組成四維時空，構成宇宙的基本結構。時間與空間在測量上都不是絕對的，觀察者在不同的相對速度或不同時空結構的測量點，所測量到時間的流逝是不同的。
就此打住，再下去的專業知識就要讓人抓狂了，比如時空扭曲。好在這些不是我們今天要聊的話題。
再玄一點試試？
愛因斯坦認為：“現在、過去和將來之間的差別只是一種錯覺。”這句話對時間的存在與否提出了質疑。無獨有偶，佛教的創立者釋迦牟尼也沒有正面回答過時間的存在問題。佛經多以“一時”開頭，比如大乘經典《華嚴經》:“如是我聞，一時，佛在摩竭提國阿蘭若法菩提場中，始成正覺。”另外，佛經里對于時間長度也常用“一彈指”“一剎那”等詞語描述。可見佛學的理論體系中也并沒有對時間的精確定義，這種獨特的時間觀和現代物理學非常接近。
差不多該切入正題了
以上是分別從日常生活，現代物理學，宗教等三個角度對于時間的認知。到現在為止，我們應該知道時間并非客觀精確存在的東西。但是生活中時間是如此的重要，人類的群體活動必須有一個時間作為準則，否則就亂套了。那怎么辦？很簡單，靠約定。
約定時間可以讓一個群體準確的完成任務。注意：約定發起者的時間就算是錯誤的，也不影響這個群體完成任務，只要活動期間內的群體內部時間是一致的就行。
“同志們，對一下時間，準備行動”小時候看電視記得最清楚的臺詞就是這一句。
計算機里的時間是如何確定的呢？
學過計算機系統的同學應該都知道，計算機中的CPU并不負責計時。計算機是靠一個叫做時鐘芯片的東西來產生時鐘脈沖推動工作的，它就像電腦的心臟一樣，持續穩定的周期性跳動。所以計算機經過時間校對后，接下來這個時鐘芯片的穩定性將直接關系到這臺計算機的時間后續是否會出現偏差。時鐘芯片就像一個樂隊的指揮家，指揮計算機的各個組件按一樣的節奏協同工作。
單機工作對時間的要求是最低的
就單個計算機來講，計算機的CPU，內存和輸入輸出等設備都在同一個時鐘芯片的指揮下工作，所以就算這臺計算機的實際時間不準確，也不會影響計算機的正常工作。
最大的麻煩來了，多臺計算機協同工作
上圖中3臺服務器和客戶的手機都處于不同的時間。如果要聯合完成一項任務，比如接受一個客戶的訂單，究竟系統該以哪個時間作為訂單產生的時間呢？
通常對于一個系統來說，越往系統內部時間越可信。比如上圖中客戶手機的時間是最不可信的，因為一千個客戶的手機時間可能各不相同。后面的3臺服務器，選任何一臺服務器的時間作為訂單產生的時間都是可以的。
難道就這么簡單？
當然不是。如果系統稍微復雜一點，比如訪問量大了以后，WEB服務和應用服務都要由多臺服務器來支持，如下圖。
這時候我們發現，只有最后面的數據庫服務器是單臺的，其他節點都變成了多臺服務器。這樣的系統結構在中小系統里面很常見。一般都會選取數據庫服務器作為時間標準，比如在數據庫中插入訂單庫記錄的時候由數據庫生成時間戳作為訂單的產生時間。
生意越來越好，系統需要進一步擴容
隨著客戶進一步增多，系統壓力越來越大，數據庫也要拆分成多臺服務器，如下圖。
現在，那臺唯一的作為時間標準的數據庫服務器也不存在了。我們應該怎么做？在目前對時間的認知程度上，很難再討論這個問題的解決方案了。所以，讓我們先離開這個問題，回到對時間的認識上來。
我們需要對時間多一點認識
我們列出時間的幾個重要特性如下，之后會逐一進行分析，并運用到分布式架構中來嘗試解決時間這個難題。
時間是靠約定的
可接受的時間精度
不存在真正的并發，凡事有先后
讓我們從第一個特性開始吧。
一個群體只要約定好一個時間作為群體標準時間就可以了。作為一個封閉的群體，時間標準只需要一個。而現實中的世界也就像一個封閉的系統，整個地球的人類只需要約定一個時間作為世界標準時間就可以了。
在系統架構中，我們就可以嘗試引入一個叫做時間仲裁的服務節點來幫助整個系統約定時間，如下圖所示：
但是實際上問題還遠不止這么簡單，如果系統足夠龐大，就需要有多個服務器群，且服務器還不在同一個機房，甚至不在同一個城市。這時候我們就需要一個頂級時間仲裁服務節點，然后每個機房的時間仲裁節點需要跟這個頂級節點同步。對于時間精度要求一般的系統來說，可以通過NTP網絡時間協議（Network Time ）來把計算機的時鐘和UTC世界協調時（ Time ）進行同步。它的對時精度在局域網內可達0.1ms，在互聯網上大概能達到1-50ms。
我看一下實際場景中的NTP應用示意圖：
即便約定了標準時間，系統內各個節點的時間依然是不絕對一致的。為什么？因為時間同步需要通過網絡進行，而網絡是有延遲的。實際環境中，每臺服務器到時間仲裁節點的網絡條件是不一樣的，所以各臺服務器之間依然會有細小的時間差異。面對這種現狀，我們需要妥協，只要保證在業務可接受精度內的時間一致就行了。
一般來說，大部分業務的時間精度需求在秒級，少數電商和金融領域的需求在毫秒級，微秒級的需求不多見。時間同步問題之所以沒有特別顯著，因為大部分同學經歷的業務場景需求在秒級就可以滿足了。實際狀況，筆者這幾年經歷的真實生產環境中，服務器時間誤差達到分鐘級的都很常見。這樣的時間誤差，就要引起重視了。
任何兩件事情，都不會在同一個時間點發生。時間是線性的，是連續不斷的，用數字的方式去表示時間，是天生有缺陷的，會有時間測量顆粒度問題。理論上，只要技術夠先進，時間的度量單位可以不斷縮小。所以我們可以推斷，世界上任何兩件事情都不可能絕對的同時發生，一定是有先后的。也就是說，沒有真正的所謂的并發。通常所說的并發，準確的說是在一定時間段內的請求總數，比如1秒內的請求數。
讀到這里，我們明白在理論上并不存在真正并發的兩個事件，但是在計算機系統中，對時間模擬的顆粒度并不是無限小的。比如現在常見的內核版本2.6的Linux系統服務器的節拍值是每秒1000次，也就是說時間的精確度在1毫秒，如果通過CPU時鐘計數，可以達到微秒級。對這部分內容感興趣的同學可以參閱《深入理解Linux內核》。
于是我們可以得出結論，在計算機世界中，由于時間顆粒度模擬的限制，會存在毫秒級別的多事件并發。
來回顧一下剛才說明的三個重要的時間特征
時間是靠約定的
可接受的時間精度
不存在真正的并發，凡事有先后
當我們一開始對時間的這幾個特征并不了解的時候，也并不影響我們實施分布式架構。但是隨著架構的深入和系統的日漸龐大，一旦出現問題后，我們就必須要對時間有清楚的認識才能獲得有效的改進方案。
接下來我們看看基于上述特征的幾個應用
應用1. 提前約定全局可用的時間
在本文前面的例子中，我們發現依靠后端數據庫節點來約定時間在分布式架構下是不可靠的。我們可以考慮把時間約定的環節前移。比如在業務請求進入的時候，由一個類似時間仲裁的節點來統一分配全局范圍內可辨識的業務發生時間。時間仲裁節點可以根據系統的實際業務需求，選擇合適的時間精度。之后，系統內任意節點在處理這條事件記錄的時候，都以這個時間為準。
應用2. 針對并發可以使用隊列實現先來后到
把所有事件全部壓入一個隊列。把進入隊列的時間約定為事件發生的時間，按照先進先出（FIFO）的原則公平的處理所有事件。這個辦法簡單有效，很多使用了隊列的系統都獲得了這個利益。但是對于更大的系統，比如使用了多個隊列，那么會面臨另外一個問題，就是隊列之間的時間同步。這似乎是一個無底洞，但是在實際業務設計中，這并不難解決。我們可以把同類型業務的所有事件安排在同一個隊列中進行，這樣就解決了多隊列的時間同步問題。目前流行的隊列系統，比如Kafka等，都支持集群部署，可以避免單點故障。如下圖所示：
應用3. 實現分布式架構下的事件全局有序回放
這是一個非常有挑戰的事情。以往單機系統中，事件回放很容易，因為所有事件都有一個時間戳，這個時間戳是基準一致的。但是在分布式架構中，事件的時間戳沒有一個統一的基準，集群中的每一臺服務器時間都不完全一致，要做到精準有序的回放，幾乎是不可能的事情。
眾所周知，目前的分布式架構多用到了微服務。微服務是高內聚、低耦合的，每個服務單元都可以完成一個基本的任務，如果要協同其它微服務一起完成一個任務，就需要使用消息通訊。每個微服務單元因為高度自治，所以日志也是各自獨立的。這樣一來系統中就沒有一個中心點負責全局日志，避免了系統中日志瓶頸點的存在的同時，也帶來一些副作用。如果強行把每個服務的日志集合到一起，因為每個服務所在的服務器時間是不一樣的，歸集后的日志也無法實現全局有序的回放。
基于本文對時間的認識，我們嘗試尋找解決方案。首先想到的是能不能在全局約定一個標準時間，比如引入時間仲裁服務。然后考慮究竟時間應該精確到什么程度才能滿足需求。因為計算機的硬件限制，日志時間通常只能達到毫秒級別，再加上網絡延遲抖動，我們不可能在一個復雜的分布式網絡中對時間精度提出苛刻的要求。最后依據不存在真正的并發，事件必定有先后的原則，我們考慮是否可以引入一個計數器來標記事件的先后。
我們先來看一個圖：
圖中一共ABCD四個節點。最初由A節點先后發出m1和m2兩個消息，分別發給B和C節點。B和C節點處理完事件后，先后發出m3和m4兩個消息給D節點。由于時間精度的關系，實際先發出的m3和后發出的m4擁有相同的時間戳。當系統回放所有事件的時候，m3和m4就無法區別先后，很有可能m4被先于m3回放，而導致錯誤。
現在我們嘗試提出方案。既然使用精準的時間是一條不歸路，那么我們就引入一個叫做邏輯時間的概念。邏輯時間是一種組合的時間表示方式，即：精準時間+偏移量。表示為{T,C}，兩個邏輯時間比較的規則是先看T分量哪個大，如果相等，再看C分量。
邏輯時鐘服務作為一個服務層在系統中的位置如圖：
當事件通過消息在系統內傳遞的時候，邏輯時鐘服務會分配該事件到達各個處理節點的邏輯時間，保持全局有序。當我們需要全局回放事件的時候，我們可以把位于各個微服務節點的日志記錄收集到統一日志服務器，然后通過歸并排序，使日志有序，最后按邏輯時間進行重放即可。由于邏輯時間中的基準時間部分和物理時間比較接近，所以也可以進行倍速重演。
改造后的方案如圖所示：
當D節點收到m3和m4的時候，會向邏輯時鐘服務申請全局唯一的邏輯時間。m3和m4因為先來后到的關系，分別獲得偏移量001和002，這樣在事件回放的時候就可以準確的判斷順序了。
當然，這只是一個簡單的方案，實際在生產環境中，我們還要考慮很多問題。比如細心的同學可能已經發現問題了，如果大量的事件傳遞都要由邏輯時鐘服務層來統一提供時間服務，就會對這個時鐘層形成很大的壓力，可能會成為新的性能瓶頸。所以，這個時鐘服務層也必須是一個去中心化的設計。有興趣的同學可以參閱以下主題的文章，比如Raft（分布式一致性算法），以及邏輯時鐘（Lamport Clock）等等。本文不再深入。
最后，我們做一點總結
時間和空間是構成這個世界的重要基準元素。軟件系統的復雜性，很多時候是在解決時間和空間的問題。越來越多的架構師已經認識到中國傳統文化中“天人合一”思想的意義。比如在計算機中尋找隨機數種子是一個難題，因為計算機系統是一個確定的系統，沒有真正的隨機。于是有人使用大氣噪音（ Noise）這種大自然的隨機現象來產生隨機數序列，效果非常不錯。道法自然，也許是解決軟件系統架構難題的最后一枚銀彈。
最后希望這篇文章可以拋磚引玉，引發同學們更多的思考，謝謝。
任何問題歡迎聯系作者，個人微信號 ，歡迎交流。
。
。
精彩原創文章投稿有驚喜！
歡迎投稿！
VSRC歡迎精品原創類文章投稿，優秀文章一旦采納發布，將為您準備的豐富獎金稅后1000元現金或等值禮品，上不封頂！如若是安全文章連載，獎金更加豐厚，稅后10000元或等值禮品，上不封頂！可點擊“閱讀原文”了解規則。（最終獎勵以文章質量為準。活動最終解釋權歸VSRC所有）
我們聆聽您寶貴建議
不知道，大家都喜歡閱讀哪些類型的信息安全文章？
不知道，大家都希望我們更新關于哪些主題的干貨？
現在起，只要您有任何想法或建議，歡迎直接回復本公眾號留言！
精彩留言互動的熱心用戶，將有機會獲得VSRC贈送的精美獎品一份！
同時，我們也會根據大家反饋的建議，選取熱門話題，進行原創發布！
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
