部落格

  • 研究:伊波拉疫情將隨二氧化碳濃度升高而擴大

    研究:伊波拉疫情將隨二氧化碳濃度升高而擴大

    環境資訊中心外電;姜唯 翻譯;林大利 審校;稿源:Carbon Brief

    根據發表在《自然通訊(Nature Communication)》的,當大氣中溫室氣體濃度升高,非洲伊波拉疫情爆發的威脅也將隨之增加。

    隨著氣溫上升,蝙蝠和其他會將病毒傳播給人類的動物可能遷移到新的區域,進而帶來疾病。

    新的模型顯示,如果人口繼續快速增加但發展緩慢且沒有相應的氣候行動,那麼到2070年,伊波拉疫情平均每10年就會爆發一次,今日的平均值是每17年一次。目前還不是疫區的西非和中非也可能受影響。

    該研究的結論是,在當前的經濟增長速度和高碳排放水準下,高風險區域的總面積可能擴大五分之一。在更高的碳排放水準下,甚至可能擴大1/3。

    作者們說,他們於2018年建立統計模型,成功預測了剛果民主共和國當前的疫情,目前伊波拉在當地已經奪走了兩千多條生命。

    因此,他們認為,這份研究當為非洲(包括過去認為未受影響的地區)針對性的伊波拉疫苗計畫和醫療基礎設施的部署奠定基礎。

    獅子山共和國境內努力對抗伊波拉病毒蔓延的村民。 (CC BY-NC-ND 2.0)

    伊波拉病毒於1976年首次被發現,2014年爆發疫情,造成西非成千上萬人喪生,在世界各地成為頭條新聞。

    一般認為這種傳染病是透過所謂的「溢出物感染」從蝙蝠和其他動物宿主傳播給人類的,是一種人畜共通傳染病。所有人類會感染的傳染病中,有2/3是人畜共通傳染病。

    伊波拉病毒一旦感染人類,就可經由直接接觸在人與人之間傳播。人類的症狀包括發燒、嘔吐,有時還包括內部和外部出血。平均死亡率約為50%。

    由於伊波拉疫情可能造成重大傷亡,科學家們必須了解下一次伊波拉疫情可能在何時何地爆發,以便分配醫療資源。

    但是,由於伊波拉自發現以來,確認的疫情暴發僅有23次,很難用傳統預測常見傳染病(如流感)的方法預測。

    伊波拉防疫措施。來源: 。(CC BY 2.0)

    倫敦大學學院的雷丁(David Redding)博士、瓊斯(Kate Jones)博士及其團隊沒有用以前的爆發資料進行研究,而是「由下而上」建立伊波拉爆發的風險模型。

    他們使用的資料包含許多因子,包括寄主分布、人口數、陸上交通、空中交通、以及土地利用類型。

    該分析的一個關鍵要素是氣候變遷,它既能影響當地社會經濟發展,也可以影響疾病傳播,而且正如雷丁所說,「在我們的模型中,大部分氣候的影響來自於為攜帶疾病的物種提供更好的條件,從而擴大了其地理分布範圍。」

    儘管究竟哪些動物能將伊波拉病毒傳給人類仍存在一些不確定性,最主要的嫌犯是大型狐蝠,而這種狐蝠常常被人類獵來吃。這些動物喜歡溫暖和潮濕的棲息地,隨著氣候變遷,高風險地區的棲息地還可能擴張。

    分析中還納入了其他可能是傳染途徑的動物,如猿類和麂羚。

    研究人員指出,從他們觀察到的結果看來,氣候的作用不如貧窮(後者與醫療保健的反應密切相關)和人口數。

    但他們也發現,溢出物感染隨著溫室氣體濃度的增加而增加。雷丁說,「在我們的模型中,負面影響隨著排放增加越來越明顯。」

    研究人員開發出一個可模擬西非流行的薩伊伊波拉病毒(Zaire Ebola virus, EBOV)人傳人和動物傳人的模型。

    科學家用圖示說明在不同排放情境下的伊波拉病毒擴散風險。來源:

    為了評估複雜的社會、經濟和氣候因素對非洲未來伊波拉病毒傳播的影響,研究團隊將氣候變遷情境中的代表濃度途徑(representative concentration pathways, RCPs)和共享社會經濟途徑(shared socio-economic pathways, SSPs)納入其模型。

    RCPs代表不同程度的氣候行動導致溫室氣體濃度不斷升高的情境。SSP代表各種社會經濟發展情境,涉及全球社會、人口統計和經濟學的不同狀況。

    接著,研究人員使用這些模型來預測到2070年非洲不同地區的伊波拉疫情風險變化。在大多數情境中,模擬結果顯示伊波拉發病率隨時間持續增加。

    但是,在永續發展和氣候變遷大規模緩解的情境,伊波拉疫情風險普遍下降。

    在現況條件下,模型預測,由溢出物感染引發的流行病大約每17年發生一次。流行病爆發在此定義為規模在1,500名患者以上的感染狀況。

    團隊使用現況條件進行了約1,500次年度模擬,發現其中約有5.8%發生了疫情爆發。接著使用不同的條件組合重複此過程。

    最大的增長發生在高排放、高人口增長和經濟發展緩慢的情況下(RCP6.0和SSP3),疫情幾乎每10年爆發一次。(論文的原始摘要寫道,在此情況下,疫情爆發的可能性比今日高出四倍,但是正確應是1.6倍。Carbon Brief與作者聯繫後確認了這一點。)

    在最樂觀的情境下(假定排放量適中且發展迅速,即RCP4.5和SSP1),頻率下降到大約每30年一次。

    模型也顯示,影響超過200萬人的「災難性疫情爆發」模式也很類似。目前這種事件預估每43年發生一次,但根據模擬,在高排放情境下,它們的發生頻率也將增加。

    模型還預測有爆發風險的區域會擴大。例如,在最樂觀的社會經濟和氣候情況下,有爆發風險的總面積與今天相比減少了近一半(分別是40萬平方公里和80萬平方公里)。

    相比之下,在低度氣候變遷緩解和中度發展(RCP6.0和SSP2)情境下,該面積增加了20.5%;在更極端的情況(RCP8.5和SSP3)下,該面積進一步增加了34%。

    值得注意的是,許多傳染病是透過環境傳播(例如水或土壤傳播),但伊波拉病毒是透過宿主之間的直接接觸傳播。這表示儘管蝙蝠和人類直接受到氣候變遷的影響,但病毒本身卻不太容易受氣候變遷影響。

    該論文的結論是,因應氣候變遷的全球性承諾也許有助降低伊波拉病例。但是對於這種推測不應太樂觀,因為「證據顯示不太可能發生全面性的改變」。

    「在中部和西部非洲減少貧困以及增加醫療資源,似乎是降低全球未來伊波拉疫情風險最現實的方法。」

    除了準確地找出已知有伊波拉疫情的地區外,該模型還確定了尼日、迦納和肯亞等國家都很可能受小規模溢出物感染和伊波拉疫情影響,儘管這些國家從來沒傳出伊波拉疫情過。

    Ebola epidemics will ‘increase with greenhouse gas concentrations’, study finds by Josh Gabbatiss

    The threat of Ebola outbreaks across Africa will increase as levels of greenhouse gases in the atmosphere rise, according to new research.

    With warming temperatures, bats and other animals that are thought to transmit the virus to humans are expected to move into new areas, bringing the disease with them. 

    The new modelling suggests that by 2070 epidemics could break out, on average, once every 10 years, if rapid population growth and slow development are accompanied by inaction on climate change. Under today’s conditions, the average is once every 17 years.

    According to the analysis, published in , changing conditions may also affect regions of West and Central Africa that are not currently considered at risk.

    The paper concludes that with current rates of economic growth and high emissions, the total epidemic-prone area could expand by a fifth. At even higher levels of emissions, it could expand by a third.

    The scientists behind the work say their modelling, which was undertaken in 2018, has already successfully predicted the currently underway in the Democratic Republic of Congo that has claimed more than 2,000 lives.

    With this in mind, they say the analysis should lay the groundwork for targeted Ebola vaccine programmes and healthcare infrastructure in Africa, including regions previously thought to be unaffected.

    Modelling everything

    First identified in 1976, Ebola around the world in 2014 when of epidemic proportions killed thousands of people in West Africa.

    The viral disease is thought to pass to humans from bats and other animal hosts in so-called “spillover events”. It is one of the many “zoonotic”, or animal-borne, diseases that make up of all human infectious diseases. 

    Once spread to humans, Ebola can be transmitted from person to person through direct contact. in humans include fever, vomiting and sometimes both internal and external bleeding. The average fatality rate is around 50%.

    Given its potential to inflict significant harm, it is vital that scientists understand when and where the next outbreak of Ebola is likely to strike so that medical resources can be directed accordingly.

    However, as there have only been around 23 confirmed outbreaks since the disease was discovered, traditional methods used to predict common infections, such as flu, are difficult.

    Instead of working from previous outbreak data, of , along with his colleague and their team, developed an outbreak risk model “from the bottom-up”. 

    They used data on a range of factors including host distribution, human population size, people’s movements by roads and air, and land use.

    , who leads the group at the and was not involved in the study, tells Carbon Brief that combining all these factors into a model is “extremely complex”. “Therefore, I am impressed by this work,” he says.

    One vital component of the analysis was climate change, which can influence disease spread both by affecting both local socioeconomic development and, as Redding tells Carbon Brief, the host species themselves:

    “In our model most of the climate effects are through better conditions for the disease-carrying species, thus increasing their native geographical range.”

    While there is still about precisely which animals pass Ebola on to humans, the prime suspects are large fruit bats that are often hunted . These creatures are known to prefer warm and wet habitats, which are expected to expand in the target regions as the climate changes.

    Other animals thought to provide alternative routes for infection, such as apes and duiker antelopes, were also considered in the analysis.

    The researchers note that climate played a less important role in their observed outcomes than poverty – which is closely tied with healthcare response – and human population size. 

    However, they also note that spillover events “increased with greenhouse gas concentrations”. Redding explains:

    “There is a positive association in our model results with increasingly more negative impact with higher emission scenarios.”

    Epidemic expansion

    The researchers developed a model that simulated animal-to-human and human-to-human transmission of Zaire Ebola virus (EBOV), the strain responsible for the West African epidemic.

    In order to gauge the impact of complex social, economic and climate factors on future Ebola transmission in Africa, the team then incorporated representative concentration pathways () and shared socio-economic pathways () into their modelling.

    RCPs broadly represent scenarios with ever-higher levels of greenhouse gases resulting from different levels of climate action. SSPs are for various socioeconomic development scenarios, involving different outcomes for global society, demographics and economics.

    (For more, see Carbon Brief’s recent on RCP8.5 and Carbon Brief’s SSP .)

    The researchers then used these models to project changes in Ebola risk across different African regions by the year 2070.

    Writing in their paper, they say their simulations suggest a “general, ongoing increase in Ebola incidence over time” for most scenarios.

    However, for scenarios involving sustainable development and extensive climate mitigation, there was a general decrease in Ebola risk (the chart below gives an idea of changing risk in different scenario combinations).

    Change in future risks of Ebola virus disease under different RCP and SSP scenarios. Each map represents mean change in “per grid cell probability” of an Ebola case from zero (yellow) to −0.06 (dark blue) and 0.06 (red), aggregated at a country level with data from the group’s model for 2070. Source: Redding et al. (2019)

    Under current conditions, the models predict an epidemic resulting from a spillover event will occur roughly once every 17 years. An epidemic was defined as an outbreak involving more than 1,500 patients.

    To arrive at this conclusion, the team ran around 1,500 yearly simulations using present day conditions and found that epidemics occurred in approximately 5.8% of them. This process was then repeated using different sets of conditions.

    The greatest increase occurs in a scenario with high emissions, high population growth and slow economic development (RCP6.0 and SSP3), with epidemics expected to occur nearly once every 10 years.

    (The likelihood of epidemics occurring under these conditions compared to present day was incorrectly described as four times more likely, instead of 1.6 times more likely, in the paper’s original abstract. The authors confirmed this after Carbon Brief contacted them about the discrepancy.)

    Under the most optimistic of the scenarios they used – which assumes moderate emissions and high development (RCP4.5 and SSP1) – the occurrence drops to roughly once every 30 years.

    A similar pattern is expected to play out for “catastrophic epidemics” affecting more than two million people. These events are currently predicted to take place once every 43 years, but the modelling suggests they will increase in frequency under high-emissions scenarios.

    The models also predict an expansion in the area at risk from outbreaks. For example, under the most optimistic socioeconomic and climate scenario, the total area where epidemics could start decreased by nearly half compared to present day (0.4m square kilometres, km2, compared to 0.8m km2).

    In comparison, in a scenario involving low climate mitigation and “middle of the road” development (RCP6.0 and SSP2), this area increased by 20.5%, Under a more extreme scenario (RCP8.5 and SSP3) this increased further, by 34%.

    Disease and climate

    While the links between climate and Ebola, Redding and his co-authors think this is the first attempt to model future transmission of the disease that takes climate change into account.

    Baylis says there has been extensive work exploring direct links between changing climate and the spread of disease – for example, in the Kenyan highlands and malaria risk. 

    However, while work from his own group has suggested of infectious diseases are susceptible to climate, he says identifying these links can be challenging:

    “Attribution is difficult, because we are really saying that climate change increases the probability of an event, but extreme events are expected even without climate change.”

    It is worth noting that while many infectious diseases are transmitted via the environment (by way of water or soil, for example), Ebola moves via direct contact between hosts. This means while bats and humans are affected directly by the changing climate, the virus itself is less susceptible to a changing climate.

    The paper concludes that global commitments to tackle climate change may drive down Ebola cases. However, it is not optimistic about this outcome, noting “evidence suggests a wholesale change is unlikely”:

    “Efforts to decrease poverty in Central and Western Africa with a concomitant increase in healthcare resources, therefore, would appear to be the most realistic approach to reducing future Ebola virus disease risk globally.”

    Future response

    Besides accurately identifying the known endemic area for Ebola, the modelling also identifies countries such as Nigeria, Ghana and Kenya as vulnerable to both small spillovers and epidemics of Ebola, despite never having been the source of such outbreaks before.

    The team says their approach “somewhat contradict[s] analyses based on current case data”.

    According to Baylis, the team’s validation of past outbreaks using the new approach increases confidence in future predictions, but notes the models are still “likely constrained by the quality of our knowledge of Ebola hosts, which is not high”.

    Besides identifying a “much larger” area within Africa that is vulnerable to spillover events, the team also incorporated information about airline routes and concluded that China, Russia, India, the US and many European countries were at risk of importing the disease.

    According to Redding, their work “acts as a call” for both a better understanding of where Ebola outbreaks could hit, plus the need for cooperation between wealthier and poorer countries to improve healthcare resources in preparation. He concludes:

    “Such an approach is a no-lose situation as better containment facilities and barrier nursing, for example, could protect nations and their neighbours against many different future disease outbreaks, not just Ebola.”

    ※ 全文及圖片詳見:()

    ※ 論文資料:Redding, D. et al. (2019) Impacts of environmental and socio-economic factors on emergence and epidemic potential of Ebola in Africa, Nature Communications,

    作者

    如果有一件事是重要的,如果能為孩子實現一個願望,那就是人類與大自然和諧共存。

    於特有生物研究保育中心服務,小鳥和棲地是主要的研究對象。是龜毛的讀者,認為龜毛是探索世界的美德。

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※別再煩惱如何寫文案,掌握八大原則!

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※超省錢租車方案

    ※教你寫出一流的銷售文案?

    網頁設計最專業,超強功能平台可客製化

  • 用剛果童工挖鈷致死或殘 5科技巨頭挨告

    摘錄自2019年12月17日聯合報報導

    特斯拉、蘋果、微軟、戴爾、Google母公司字母(Alphabet)以共謀罪名被告上法庭。這是科技業首次因其鈷來源,共同面臨法律訴訟。

    代表剛果民主共和國14個家庭擔任原告的美國人權組織「國際權利倡議」(International Rights Advocates)15日提告五家全球大型科技公司,指強迫勞動的體系導致這些家庭的小孩死亡或重傷,而五家科技業者是這個體系的一部分。

    這起訴訟說,案件裡的兒童,最小的才6歲,因為出身赤貧家庭,不得不休學到嘉能可的礦坑挖鈷。他們每周要工作六天,有些人領的日薪低到只有1.5美元(約台幣45元)。

    鈷是製造科技產品內部可重複使用鋰電池的必要材料。全球一半以上的鈷產自剛果民主共和國。根據歐盟執委會2018年的一份研究,未來10年全球鈷需求料將每年增加7%到13%。原告主張,挨告的科技業者全都有能力徹底整頓旗下鈷供應鏈,以確保更安全的工作條件。

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※教你寫出一流的銷售文案?

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※回頭車貨運收費標準

    ※別再煩惱如何寫文案,掌握八大原則!

    ※超省錢租車方案

    ※產品缺大量曝光嗎?你需要的是一流包裝設計!

  • 跟殺蟑盒一樣的殺蜂盒 日網友:不分蜂類都傷害到怎麼辦呢?

    文:宋瑞文

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※超省錢租車方案

    ※別再煩惱如何寫文案,掌握八大原則!

    ※回頭車貨運收費標準

    ※教你寫出一流的銷售文案?

    FB行銷專家,教你從零開始的技巧

  • 【K8S學習筆記】初識K8S 及架構組件

    【K8S學習筆記】初識K8S 及架構組件

    K8S是什麼?發展歷史

    Kubernetes (簡稱 k8s)是 Google 在2014年開源的,對容器生命周期管理的開源平台,致力於對容器集群提供易於管理、高可用、彈性負載與故障轉移的能力,提高服務運維自動化的能力。

    最初,Google 開發了一個叫 Borg 的系統(現在命名為Omega)來調度據說有20多億個容器和工作負載。在積累了 10 余年經驗后,Google 決定重寫這個容器管理系統,並將其命名為 Kubernetes 貢獻給開源社區,讓全世界都能因此受益。

    自從開源以來,K8S迅速獲得開源社區的追捧,包括RedHat、VMware、Canonical在內的有很大影響力公司加入到開發與推廣的陣營。

    當微服務的概念的落地實踐開始,微服務就與容器緊緊地綁在了一起,可以說K8s的成功離不開微服務與容器。

    2017年是容器生態發展歷史中具有里程碑意義的一年。

    在這一年,長期作為Docker競爭對手的RKT容器一派的領導者CoreOS宣布放棄自己的容器管理系統Fleet,未來將會把所有容器管理的功能移至Kubernetes之上去實現。

    在這一年,容器管理領域的獨角獸Rancher Labs宣布放棄其內置了數年的容器管理系統Cattle,提出了“All-in-Kubernetes”戰略,從2.0版本開始把1.x版本能夠支持多種容器管理工具的Rancher,“升級”為只支持Kubernetes一種容器管理系統。

    在這一年,Kubernetes的主要競爭者Apache Mesos在9月正式宣布了“Kubernetes on Mesos”集成計劃,由競爭關係轉為對Kubernetes提供支持,使其能夠與Mesos的其他一級框架(如HDFS、Spark 和Chronos,等等)進行集群資源動態共享、分配與隔離。

    在這一年,Kubernetes的最大競爭者Docker Swarm的母公司Docker,終於在10月被迫宣布Docker要同時支持Swarm與Kubernetes兩套容器管理系統,事實上承認了Kubernetes的統治地位。這場已經持續了三、四年時間,以Docker Swarm、Apache Mesos與Kubernetes為主要競爭者的“容器戰爭”終於有了明確的結果。

    時至今日,K8S 已經是發展最快、市場佔有率最高的容器編排系統,是業界標杆。

    小結:Kubernetes是Google公司2014年開源的容器編排產品,經過多年的發展,已經成為容器編排領域的佼佼者,擁有最廣大的用戶群體

    應用部署容器化的發展歷程

    要說K8S的作用,得先從容器的發展與優勢講起,大致可分為 傳統部署時代、虛擬化部署時代、容器部署時代

    傳統部署時代: 早期,在物理服務器上運行應用程序。無法為物理服務器中的應用程序定義資源邊界,這會導致資源分配困難與資源浪費的問題。例如,如果在物理服務器上運行多個應用程序,則可能會出現一個應用程序佔用大部分資源的情況,結果可能導致其他應用程序的性能下降。一種解決方案是在不同的物理服務器上運行每個應用程序,但是由於資源利用不足而無法擴展,並且組織維護許多物理服務器的成本很高

    虛擬化部署時代: 作為解決方案,引入了虛擬化功能,它允許您在單個物理服務器的 CPU 上運行多個虛擬機(VM)。虛擬化功能允許應用程序在 VM 之間隔離,並提供安全級別,因為一個應用程序的信息不能被另一應用程序自由地訪問。

    因為虛擬化可以輕鬆地添加或更新應用程序、降低硬件成本等等,所以虛擬化可以更好地利用物理服務器中的資源,並可以實現更好的可伸縮性。

    每個 VM 是一台完整的計算機,在虛擬化硬件之上運行所有組件,包括其自己的操作系統,這勢必也會造成資源的浪費、性能的下降

    容器部署時代: 容器類似於 VM,但是它們具有輕量級的隔離屬性,可以在應用程序之間共享操作系統(OS)。因此,容器被認為是輕量級的。容器與 VM 類似,具有自己的文件系統、CPU、內存、進程空間等。由於它們與基礎架構分離,因此可以跨雲和 OS 分發進行移植

    容器因具有許多優勢而變得流行起來。下面列出了容器的一些好處

    • 敏捷應用程序的創建和部署:與使用 VM 鏡像相比,提高了容器鏡像創建的簡便性和效率。
    • 持續開發、集成和部署:通過快速簡單的回滾(由於鏡像不可變性),提供可靠且頻繁的容器鏡像構建和部署。
    • 關注開發與運維的分離:在構建/發布時而不是在部署時創建應用程序容器鏡像,從而將應用程序與基礎架構分離。
    • 可觀察性:不僅可以显示操作系統級別的信息和指標,還可以显示應用程序的運行狀況和其他指標信號。
    • 跨開發、測試和生產的環境一致性:在便攜式計算機上與在雲中相同地運行。
    • 雲和操作系統分發的可移植性:可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方運行。
    • 以應用程序為中心的管理:提高抽象級別,從在虛擬硬件上運行 OS 到使用邏輯資源在 OS 上運行應用程序。
    • 鬆散耦合、分佈式、彈性、解放的微服務:應用程序被分解成較小的獨立部分,並且可以動態部署和管理 – 而不是在一台大型單機上整體運行。
    • 資源隔離:可預測的應用程序性能。
    • 資源利用:高效率和高密度。

    小結:相對於傳統物理機部署方式,虛擬機部署將資源更好的隔離開來,使資源分配與隔離的問題解決,提高了資源使用率,但是由於其虛擬了硬件與OS,會浪費不必要的資源;容器部署繼承了虛擬機部署的資源隔離優勢的同時,使用共享宿主機的硬件與OS的方式,資源消耗更少,由於與基礎架構進行了分離,可以做到良好的移植性

    為什麼需要 Kubernetes,它能做什麼?

    容器是打包和運行應用程序的好方式。在生產環境中,如果一個容器發生故障,則啟動另一個容器。如此處理會不會更簡單?

    K8s就是這麼做的!K8s 為您提供了一個可彈性運行分佈式系統的框架,能滿足您的擴展要求、故障轉移、部署模式等。

    Kubernetes 為您提供:

    • 服務發現和負載均衡
      Kubernetes 可以使用 DNS 名稱或自己的 IP 地址公開容器,如果到容器的流量很大,Kubernetes 可以負載均衡並分配網絡流量,從而使部署穩定。

    • 存儲編排
      Kubernetes 允許您自動掛載您選擇的存儲系統,例如本地存儲、公共雲提供商等。

    • 自動部署和回滾
      您可以使用 Kubernetes 描述已部署容器的所需狀態,它可以以受控的速率將實際狀態更改為所需狀態。例如,您可以自動化 Kubernetes 來為您的部署創建新容器,刪除現有容器並將它們的所有資源用於新容器。

    • 自動二進制打包
      Kubernetes 允許您指定每個容器所需 CPU 和內存(RAM)。當容器指定了資源請求時,Kubernetes 可以做出更好的決策來管理容器的資源。

    • 自我修復
      Kubernetes 重新啟動失敗的容器、替換容器、殺死不響應用戶定義的運行狀況檢查的容器,並且在準備好服務之前不將其通告給客戶端。

    • 密鑰與配置管理
      Kubernetes 允許您存儲和管理敏感信息,例如密碼、OAuth 令牌和 ssh 密鑰。您可以在不重建容器鏡像的情況下部署和更新密鑰和應用程序配置,也無需在堆棧配置中暴露密鑰。

    小結:K8S 提供了服務發現和負載均衡、存儲編排、自動部署和回滾、自動二進制打包、自我修復、密鑰與配置管理等功能,能滿足您的擴展要求、故障轉移、部署模式等需求

    擴展
    1、有微服務實踐的讀者可能會發現,微服務組件中的服務發現、負載均衡、網關等功能在K8s體系中都有對應的實現,那麼是不是我就可以不使用其他微服務的體系而直接擁抱K8s呢?
    答案是可以的。但有一點限制就是開發人員要學習K8s,偏向DevOps了。
    2、既然K8s提供了微服務所需的基礎組件實現,但我可以不用么?
    答案也是可行的。K8s的組件插拔能力允許你這麼做,這樣一來開發測試環境使用本地部署註冊中心等組件,開發人員就無需關心K8s了,只需要理解所用微服務框架本身,如Spring Cloud等。

    Kubernetes 不是什麼

    Kubernetes 不是傳統的、包羅萬象的 PaaS(平台即服務)系統。它只提供了 PaaS 產品共有的一些普遍適用的功能,例如部署、擴展、負載均衡、日誌記錄和監視。但是,Kubernetes 不是單一的,默認解決方案是可選和可插拔的。Kubernetes 提供了構建開發人員平台的基礎,但是在重要的地方保留了用戶的選擇和靈活性。

    Kubernetes:

    • 不限制支持的應用程序類型。Kubernetes 旨在支持極其多種多樣的工作負載,包括無狀態、有狀態和數據處理工作負載。如果應用程序可以在容器中運行,那麼它應該可以在 Kubernetes 上很好地運行。

    • 不部署源代碼,也不構建您的應用程序。持續集成(CI)、交付和部署(CI/CD)工作流取決於組織的文化和偏好以及技術要求。

    • 不提供應用程序級別的服務作為內置服務,例如中間件(例如,消息中間件)、數據處理框架(例如,Spark)、數據庫(例如,mysql)、緩存、集群存儲系統(例如,Ceph)。這樣的組件可以在 Kubernetes 上運行,並且/或者可以由運行在 Kubernetes 上的應用程序通過可移植機制(例如,開放服務代理)來訪問。

    • 不指定日誌記錄、監視或警報解決方案。它提供了一些集成作為概念證明,並提供了收集和導出指標的機制。

    • 不提供或不要求配置語言/系統(例如 jsonnet),它提供了聲明性 API,該聲明性 API 可以由任意形式的聲明性規範所構成。

    • 不提供也不採用任何全面的機器配置、維護、管理或自我修復系統

    • 此外,Kubernetes 不僅僅是一個編排系統,實際上它消除了編排的需要。編排的技術定義是執行已定義的工作流程:首先執行 A,然後執行 B,再執行 C。相比之下,Kubernetes 包含一組獨立的、可組合的控制過程,這些過程連續地將當前狀態驅動到所提供的所需狀態。從 A 到 C 的方式無關緊要,也不需要集中控制,這使得系統更易於使用且功能更強大、健壯、彈性和可擴展性。

    小結:K8S 提供了基礎的容器編排平台,但並不是大而全地將所有可能的功能都直接集成進來,而是做成可插拔的形式,可以做到因地適宜地組織與管理集群,擁有很高的靈活性。

    Kubernetes 架構與組件

    K8s的架構如上圖,左邊虛線框的部分稱為 控制平面(Control Plane),右側為 集群節點(Nodes)

    控制平面所在的主機稱為 Master 節點,其餘稱為 Nodes 執行節點

    簡單按這兩種角色來講,Master節點負責發號施令(下發命令、監控節點與容器狀態),而 Nodes 節點負責幹活

    控制平面(Control Plane)組件

    控制平面的組件對集群做出全局決策(比如調度),以及檢測和響應集群事件

    控制平面組件可以在集群中的任何節點上運行。簡單起見,通常會將控制平台配置在一台主機上,也可以配置高可用形式。

    下邊我們介紹下 控制平面中的幾大組件:

    • kube-apiserver:Master節點上負責提供 Kubernetes API 服務的組件;它是 Kubernetes 控制面的前端,由它來接收來自 CLI 與 UI 的指令
    • etcd:是兼具一致性和高可用性的鍵值數據庫,可以作為保存 Kubernetes 所有集群數據的後台數據庫。
    • kube-scheduler:Master節點上的組件,該組件監視那些新創建的未指定運行節點的 Pod,並選擇節點讓 Pod 在上面運行。
    • kube-controller-manager:控制器通過 apiserver 監控集群的公共狀態,並致力於將當前狀態轉變為期望的狀態。從邏輯上講,每個控制器都是一個單獨的進程,但是為了降低複雜性,它們都被編譯到同一個可執行文件,並在一個進程中運行。包含以下幾種控制器:
      • 節點控制器(Node Controller): 負責在節點出現故障時進行通知和響應。
      • 副本控制器(Replication Controller): 負責為系統中的每個副本控制器對象維護正確數量的 Pod。
      • 端點控制器(Endpoints Controller): 填充端點(Endpoints)對象(即加入 Service 與 Pod)。
      • 服務帳戶和令牌控制器(Service Account & Token Controllers): 為新的命名空間創建默認帳戶和 API 訪問令牌
    • cloud-controller-manager:雲控制器管理器負責與基礎雲提供商交互,以下控制器具有雲提供商依賴性:
      • 節點控制器(Node Controller): 用於檢查雲提供商以確定節點是否在雲中停止響應后被刪除
      • 路由控制器(Route Controller): 用於在底層雲基礎架構中設置路由
      • 服務控制器(Service Controller): 用於創建、更新和刪除雲提供商負載均衡器
      • 數據卷控制器(Volume Controller): 用於創建、附加和裝載卷、並與雲提供商進行交互以編排卷

    節點(Node) 組件

    節點組件在每個節點上運行,維護運行的 Pod 並提供 Kubernetes 運行環境

    節點組件包含兩大組件:

    • kubelet:一個在集群中每個節點上運行的代理。它保證容器都運行在 Pod 中。

      kubelet 接收一組通過各類機制提供給它的 PodSpecs,確保這些 PodSpecs 中描述的容器處於運行狀態且健康。kubelet 不會管理不是由 Kubernetes 創建的容器。

    • kube-proxy:是集群中每個節點上運行的網絡代理,實現 Kubernetes Service 概念的一部分。

      kube-proxy 維護節點上的網絡規則。這些網絡規則允許從集群內部或外部的網絡會話與 Pod 進行網絡通信。

      如果操作系統提供了數據包過濾層並可用的話,kube-proxy會通過它來實現網絡規則。否則,kube-proxy 僅轉發流量本身

    • 容器運行環境(Container Runtime):容器運行環境是負責運行容器的軟件。K8s支持多種容器運行環境:Docker、containerd、cri-o、rklet 以及任何實現K8s容器運行環境接口的技術。

    插件(Addons)

    • DNS:所有 Kubernetes 集群都應具有 DNS。集群 DNS 還是一個 DNS 服務器,它為 Kubernetes 服務提供 DNS 記錄。

    • 用戶界面(Dashboard):Kubernetes 集群基於 Web 的 UI。它使用戶可以管理集群中運行的應用程序以及集群本身並進行故障排除。

    Dashboard 是 Kubernetes 集群的通用基於 Web 的 UI。它使用戶可以管理集群中運行的應用程序以及集群本身並進行故障排除。

    • 容器資源監控:將關於容器的一些常見的時間序列度量值保存到一個集中的數據庫中,並提供用於瀏覽這些數據的界面。

    • 集群層面日誌:負責將容器的日誌數據保存到一個集中的日誌存儲中,該存儲能夠提供搜索和瀏覽接口。

    小結:K8s架構分為控制平台位於的Master節點與執行節點Node

    控制平台包含:

  • kube-apiserver(訪問入口,接收命令)
  • etcd(KV數據庫,保存集群狀態與數據)
  • kube-scheduler(監控節點狀態,調度容器部署)
  • kube-controller-manager(監控集群狀態,控制節點、副本、端點、賬戶與令牌)
  • cloud-controller-manager(控制與雲交互的節點、路由、服務、數據卷)
  • 執行節點包含:

  • kubelet(監控與實際操作容器)
  • kube-proxy(每個節點上運行的網絡代理,維護網絡轉發規則,實現了Service)
  • 容器運行時環境CRI(支持多種實現K8s CRI的容器技術)
  • 本文總結

    Kubernetes 作為容器編排的領航者,將容器化的優勢發揮得淋漓盡致,排除了容器難於管理的問題。

    按角色來看,K8s可以分為兩部分,控制平面與執行節點,控制平台通過一系列接收指令、監控、部署調度等功能的組件組成,最主要的有kube-apiserver、etcd、kube-scheduler、kube-controller-manager;執行節點包含負責監控與具體幹活的kubelet和維護網絡規則的kube-proxy

    參考文章

    • https://kubernetes.io/docs/concepts/overview/components/

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※帶您來了解什麼是 USB CONNECTOR  ?

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    ※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!

    ※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※教你寫出一流的銷售文案?

  • Java多線程與併發基礎面試題

    CS-LogN思維導圖:記錄專業基礎 面試題
    開源地址:https://github.com/FISHers6/CS-LogN

    多線程與併發基礎

    實現多線程

    面試題1:有幾種實現線程的方法,分別是什麼

    • 1.繼承Thread類,啟動線程的唯一方法就是通過 Thread 類的 start()實例方法,start()方法是一個 native 方法,它將啟動一個新線程去執行 run()方法

    • 2.實現 Runnable 接口,重寫run()函數,作為參數放到Thread類構造函數中作為target屬性,運行start()方法

    • 線程池創建線程、Callable本質還是使Runnable創建,Callable是父輩類繼承了Runnable,線程池需傳入參數

    面試題2:實現Runnable方法好,還是繼承Thread類好

    • 實現Runnable接口更好

      • 1.單一繼承原則,如果繼承了Thread,就不能繼承其它類了,限制了可擴展性
      • 2.Thread類每次只能創建一個獨立的線程,損耗大,而Runnable能利用線程池工具來創建線程
      • 3.從代碼架構上看,run內容應該與Trhead代碼解耦

    面試題3:一個線程兩次調用start方法會出現什麼情況(考察源碼)

    • 第二次會出現異常,從start源碼上和線程生命周期上分析,一個線程start后,
      改變了threadState狀態字;而第二次再start每次會先檢查這個狀態不是0就報異常

    面試題4:既然start方法會調用run方法,為什麼我們還是要用start方法,而不是直接調用run方法呢(考察源碼)

    • 因為start后線程才會經過完整的線程生命周期,start調用native start0,虛擬機執startThread,thread_entry入口中調用Thread的run,

    面試題5:start和run有什麼區別

    • run()方法:只是普通的方法,調用run普通方法,可以重複多次調用
    • start()方法,會啟動一個線程,使得虛擬機去調用Runnable對象的run()方法,不能多次啟動同一個線程

    面試題6:start方法如何調用run方法的(考察源碼和JVM)

    • start方法調用native start0,JVM虛擬機執行startThread,在thread_entry中調用Thread的run方法

    面試題7:如何正確停止線程

    • 使用interrupt中斷通知,而不是強制,中斷通知後會讓被停止線程去決定何時停止,即把主動權交給需要被中斷的線程

    線程的生命周期

    面試題1:Java線程有哪幾種狀態 說說生命周期

    • 六種生命狀態(若time_waiting也算一種)

      • New,已創建但還尚未啟動的新線程
      • Runable,可運行狀態;對應操作系統的兩種狀態“就緒態” 和 “運行態”(分配到CPU)
      • Blocked,阻塞狀態;請求synchronized鎖未分配到時阻塞,直到獲取到monitor鎖再進入Runnable
      • Waiting,等待狀態
      • Timed waiting,限期等待
      • Terminated終止狀態
    • 線程的生命周期 狀態轉換圖

    Thread和Object類中

    與線程相關的重要方法

    面試題1:實現兩個線程交替打印奇數偶數

    面試題2:手寫生產者消費者設計模式,為什麼用該模式

    • 主要是為了解耦,匹配不同的能力

    面試題3:wait后發生了什麼,為什麼需要在同步代碼內才能使用

    • 從jvm的源碼實現上看,wait后,線程讓出佔有的cpu並釋放同步資源鎖;把自己加入到等待池,以後不會再主動參与cpu的競爭,除非被其它notify命中
    • 為了確保線程安全;另外wait會釋放資源,所以肯定要先拿到這個鎖,能進入同步代碼塊已經拿到了鎖

    面試題4:為什麼線程通信的方法wait,notify和notifyAll放在Object類,而sleep定義在Thread類里 (考察對象鎖)

    • 與對象的鎖有關,對象鎖綁定在對象的對象頭中,且放在Object里,使每個線程都可以持有多個對象的鎖

    面試題5:wait方法是屬於Object對象的,那調用Thread.wait會怎麼樣

    • 線程死的時候會自己notifyAll,釋放掉所有的持有自己對象的鎖。這個機制是實現很多同步方法的基礎。如果調用Thrad.wait,干擾了我們設計的同步業務流程

    面試題6:如何選擇notify還是notifyAll

    • 優先選用notifyAll,喚醒所有線程;除非業務需要每次只喚醒一個線程的

    面試題7:notfiy后發生的操作,notifyAll之後所有的線程都會再次搶奪鎖,如果某線程搶奪失敗怎麼辦?

    • notify后,讓waiterSet等待池中的一個線程與entry_List鎖池一級活躍線程一起競爭CPU
    • 搶奪鎖失敗後會繼續待在原鎖池或原等待池,等待競爭CPU的調度

    面試題8:sleep方法與notify/wait方法的異同點

    • 相同點:線程都會進入waiting狀態,都可以響應中斷
    • 不同點:1.所屬類不同;2.wait/notify必須用在同步方法中,且會釋放鎖;3.sleep可以指定時間

    面試題9:join方法後父線程進入什麼狀態

    • waiting狀態,join內部調用wait,子線程結束后自動調用notifyAll喚醒(jvm:exit函數)

    線程安全與性能

    面試題1:守護線程和普通線程的區別

    • 守護線程是服務於普通線程的,並且不會影響到jvm的退出

    面試題2:什麼是線程安全

    • 不管業務中遇到怎樣的多個線程訪問某對象或某方法的情況,而在編程這個業務邏輯的時候,都不需要再額外做任何額外的處理(也就是可以像單線程編程一樣),程序也可以正常運行(不會因為多線程而出錯),就可以稱為線程安全

    面試題3:有哪些線程不安全的情況,什麼原因導致的

    • 1.數據爭用、同時操作,如數據讀寫由於同時寫,非原子性操作導致運行結果錯誤,a++
    • 2.存在競爭,順序不當,如死鎖、活鎖、飢餓

    面試題4:什麼是多線程的上下文切換,及導致的後果

    • 進程線程切換要保存所需要的CPU運行環境,如寄存器、棧、全局變量等資源
    • 在頻繁的io以及搶鎖的時候,會導緻密集的上下文切換,多線程切換時,由於緩存和上下文的切換會帶來性能問題

    面試題5:多線程導致的開銷有哪些

    • 1.上下文切換開銷,如保存緩存(cache、快表等)的開銷

    • 2.同步協作的開銷(java內存模型)

      • 為了數據的正確性,同步手段往往會使用禁止編譯器優化(如指令重排序優化、鎖粗化等),性能變差
      • 使CPU內的緩存失效(比如volatile可見性讓自己線程的緩存失效后,必須使用主存來查看數據)

    Java內存模型

    面試題1:Java的代碼如何一步步轉化,最終被CPU執行的

      1. 最開始,我們編寫的Java代碼,是*.java文件
    1. 在編譯(javac命令)后,從剛才的.java文件會變出一個新的Java字節碼文件.class
    2. JVM會執行剛才生成的字節碼文件(*.class),並把字節碼文件轉化為機器指令
    3. 機器指令可以直接在CPU上執運行,也就是最終的程序執行
    • JVM實現會帶來不同的“翻譯”,不同的CPU平台的機器指令又千差萬別,無法保證併發安全的效果一致

    面試題2:單例模式的作用和適用場景

    • 單例模式:只獲取一次資源,全程序通用,節省內存和計算;保證多線程計算結果正確;方便管理;
      比如日期工具類只需要一個實例就可以,無需多個示例

    面試題3:單例模式的寫法,考察(重排序、單例和高併發的關係)

    • 餓漢式(靜態常量、靜態代碼塊)

      • 原理1:static靜態常量在類加載的時候就初始化完成了,且由jvm保證線程安全,保證了變量唯一
      • 原理2:靜態代碼塊中實例化和靜態常量類似;放在靜態代碼塊里初始化,類加載時完成;
      • 特徵:簡單,但沒有懶加載(需要時再加載)
    • 懶漢式(加synchronized鎖)

      • 對初始化的方法加synchronized鎖達到線程安全的目的,但效率低,多線程下變成了同步
      • 懶漢式取名:用到的時候才去加載
    • 雙重檢查

      • 代碼實現

        • 屬性加volatile,兩次if判斷NULL值,第二次前加類鎖
      • 優點

        • 線程安全;延遲加載;效率高
      • 為什麼用雙重而不用單層

        • 從線程安全方面、效率方面講
    • 靜態內部類

      • 需要理解靜態內部類的優點,懶漢式加載,jvm加載順序
    • 枚舉

      • 代碼實現簡單

        • public enum Singleton{
          INSTANCE;
          public void method(){}
          }
      • 保證了線程安全

        • 枚舉是一個特殊的類,經過反編譯查看,枚舉最終被編譯成一個final的類,繼承了枚舉父類。各個實例通過static定義,本質就是一個靜態的對象,所有第一次使用的時候採取加載(懶加載)
      • 避免反序列化破壞單例

        • 避免了:比如用反射就繞過了構造方法,反序列化出多個實例

    面試題4:單例模式各種寫法分別適用的場合

    • 1.最好的方法是枚舉,因枚舉被編譯成final類,用static定義靜態對象,懶加載。既保證了線程安全又避免了反序列化破壞單例
    • 2.如果程序一開始要加載的資源太多,考慮到啟動速度,就應該使用懶加載
    • 3.如果是對象的創建需要配置文件(一開始要加載其它資源),就不適合用餓漢式

    面試題5:餓漢式單例的缺點

    • 沒有懶加載(初始化時全部加載出),初始化開銷大

    面試題6:懶漢式單例的缺點

    • 雖然用到的時候才去加載,但是由於加鎖,性能低

    面試題7:單例模式的雙重檢查寫法為什麼要用double-check

    • 從代碼實現出發,保證線程安全、延遲加載效率高

    面試題8:為什麼雙重檢查要用volatile

    • 1.保證instance的可見性

      • 類初始化分成3條指令,重排序帶來NPE空虛指針問題,加volatile防止重排序
    • 2.防止初始化指令重排序

    面試題9:講一講什麼是Java的內存模型

    • 1.是一組規範,需要JVM實現遵守這個規範,以便實現安全的多線程程序
      2.volatile、synchronized、Lock等同步工具和關鍵字實現原理都用到了JMM
      3.重排序、內存可見性、原子性

    面試題10:什麼是happens-before,規則有哪些

    • 解決可見性問題的:在時間上,動作A發生在動作B之前,B保證能看見A,這就是happens-before

    • 規則

      • 1 單線程按代碼順序規則;2 鎖操作(synchronized和Lock);3volatile變量;4.JUC工具類的Happens-Before原則
      • 5.線程啟動時子線程啟動前能看到主線程run的所有內容;6.線程join主線程一定要等待子線程完成后再去做後面操作
      • 7.傳遞性 8.中斷檢測 9.對象構造方法的最後一行指令 happens-before 於 finalize() 方法的第一行指令

    面試題11:講一講volatile關鍵字

    • volatile是一種同步機制,比synchronized或者Lock相關類更輕量,因為使用volatile並不會發生上下文切換等開銷很大的行為。而加鎖時對象鎖會阻塞開銷大。
    • 可見性,如果一個變量別修飾成volatile,那麼JVM就知道了這個變量可能會被併發修改;
    • 不能保證原子性

    面試題12:volatile的適用場合及作用

    • 作用

      • 1.保證可見性 2.禁止指令重排序(單例雙重鎖時)
    • 適合場景

      • 適用場合1:boolean flag,布爾具有原子性,可再由volatile保證其可見性
      • 適用場合2:作為刷新之前變量的觸發器
      • 但不適合非原子性操作如:a++等

    面試題13:volatile和synchronized的異同

    • 1 性能開銷方面: 鎖開銷更大,volatile無加鎖阻塞開銷
      2 作用方面:volatile只能保證可見性,鎖既能保證可見性,又能保證原子性

    面試題14:什麼是內存可見性問題,為什麼存在

    • 多線程下,一個線程修改共享數據后,其它線程能否感知到修改了數據的線程的變化
    • CPU有多級緩存,導致讀的數據過期,各處理機有獨自的緩存未及時更新時,與主存內容不一致

    面試題15:主內存和本地內存的關係是什麼

    • Java 作為高級語言,屏蔽了CPU cache等底層細節,用 JMM 定義了一套讀寫內存數據的規範,雖然我們不再需要關心一級緩存和二級緩存的問題,但是,JMM 抽象了主內存和本地內存的概念。
    • 線程擁有自己的本地內存,並共享主內存的數據;線程讀寫共享數據也是通過本地內存交換的,所以才導致了可見性問題。

    面試題16:什麼是原子操作,Java的原子操作有哪些

    • 原子操作

      • 一系列的操作,要麼全部執行成功,要麼全部不執行,不會出現執行一半的情況,是不可分割的。
    • 1)除long和double之外的基本類型(int, byte, boolean, short, char, float)的”賦值操作”

    • 2)所有”引用reference的賦值操作”,不管是 32 位的機器還是 64 位的機器

    • 3)java.concurrent.Atomic.* 包中所有類的原子操作

    面試題17:long 和 double 的原子性你了解嗎

    • 在32位上的JVM上,long 和 double的操作不是原子的,但是在64位的JVM上是原子的。
    • 在32位機器上一次只能讀寫32位;而浮點數、long型有8字節64位;要分高32位和低32位兩條指令分開寫入,類似彙編語言浮點數乘法分高低位寄存器;64位不用分兩次讀寫了

    面試題18:生成對象的過程是不是原子操作

    • 不是,對象生成會生成分配空間、初始化、賦值,三條指令,有可能會被重排序,導致空指針

    面試題19:區分JVM內存結構、Java內存模型 、Java對象模型

    • Java內存模型,和Java的併發編程有關

      • 詳見面試題9
    • JVM內存結構,和Java虛擬機的運行時區域(堆棧)有關

      • 堆區、方法區(存放常量池 引用 類信息)
        棧區、本地方法棧、程序計數器

    • Java對象模型,和Java對象在虛擬機中的表現形式有關

      • 是Java對象自身的存儲模型,在方法區中Kclass類信息(虛函數表),在堆中存放new實例,在線程棧中存放引用,OOP-Klass Model

    面試題20:什麼是重排序

    • 指令實際執行順序和代碼在java文件中的順序不一致
    • 重排序的好處:提高處理速度,包括編譯器優化、指令重排序(局部性原理)

    死鎖

    面試題1:寫一個必然死鎖的例子

    • synchronized嵌套,構成請求循環

    面試題2:生產中什麼場景下會發生死鎖

    • 併發中多線程互不相讓:當兩個(或更多)線程(或進程)相互持有對方所需要的資源,又不主動釋放,導致所有人都無法繼續前進,導致程序陷入無盡的阻塞,這就是死鎖。

    面試題3:發生死鎖必須滿足哪些條件

    • 1.互斥
    • 2.請求和保持
    • 3.不可剝奪
    • 4.存儲循環等待鏈

    面試題4:如何用工具定位死鎖

    • 1.jstack命令在程序發生死鎖后,進行堆棧分析出死鎖線程
    • 2.ThreadMXbean 程序運行中發現死鎖,一旦發現死鎖可以讓用戶去打日誌

    面試題5:有哪些解決死鎖問題的策略

    • 1.死鎖語法,不讓死鎖發生

      • 破壞死鎖的四個條件之一;如:哲學家換手、轉賬換序
    • 2.死鎖避免

      • 銀行家算法、系統安全序列
    • 3.死鎖檢查與恢復

      • 適用資源請求分配圖,一段時間內檢查死鎖,有死鎖就恢復策略,採用恢復策略;
      • 恢復方法:進程終止 、資源剝奪
    • 4.鴕鳥策略(忽略死鎖)

      • 先忽略,後期再讓人工恢復

    面試題6:死鎖避免策略和檢測與恢復策略的主要思路是什麼

    • 死鎖語法

      • 破壞死鎖的四大條件之一
    • 死鎖避免

      • 找到安全序列,銀行家算法
    • 死鎖檢測與恢復

      • 資源請求分配圖

    面試題7:講一講經典的哲學家就餐問題,如何解決死鎖

    • 什麼時候死鎖

      • 哲學家各拿起自己左手邊的筷子,又去請求拿右手邊筷子循環請求時而阻塞
    • 如何解決死鎖

      • 1.一次兩隻筷子,形成原子性操作
      • 2.只允許4個人拿有筷子

    面試題8:實際開發中如何避免死鎖

    • 設置超時時間
    • 多使用併發類而不是自己設計鎖
    • 盡量降低鎖的使用粒度:用不同的鎖而不是一個鎖,鎖的範圍越小越好
    • 避免鎖的嵌套:MustDeadLock類
    • 分配資源前先看能不能收回來:銀行家算法
    • 盡量不要幾個功能用同一把鎖:專鎖專用
    • 給你的線程起個有意義的名字:debug和排查時事半功倍,框架和JDK都遵守這個最佳實踐

    面試題9:什麼是活躍性問題?活鎖、飢餓和死鎖有什麼區別

    • 活鎖

      • 雖然線程並沒有阻塞,也始終在運行(所以叫做“活”鎖,線程是“活”的),但是程序卻得不到進展,因為線程始終互相謙讓,重複做同樣的事

      • 工程中的活鎖實例:消息隊列,消息如果處理失敗,就放在隊列開頭重試,沒阻塞程序無法繼續

      • 如何解決活鎖問題

        • 加入隨機因素,以太網的指數退避算法
    • 飢餓

      • 當線程需要某些資源(例如CPU),但是卻始終得不到,可能原因是飢餓線程的優先級過低

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※為什麼 USB CONNECTOR 是電子產業重要的元件?

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※台北網頁設計公司全省服務真心推薦

    ※想知道最厲害的網頁設計公司"嚨底家"!

    ※推薦評價好的iphone維修中心

  • 關於 JOIN 耐心總結,學不會你打我系列

    關於 JOIN 耐心總結,學不會你打我系列

    現在隨着各種數據庫框架的盛行,在提高效率的同時也讓我們忽略了很多底層的連接過程,這篇文章是對 SQL 連接過程梳理,並涉及到了現在常用的 SQL 標準。

    其實標準就是在不同的時間,制定的一些寫法或規範。

    從 SQL 標準說起

    在編寫 SQL 語句前,需要先了解在不同版本的規範,因為隨着版本的變化,在具體編寫 SQL 時會有所不同。對於 SQL 來說,SQL92 和 SQL99 是最常見的兩個 SQL 標準,92 和 99 對應其提出的年份。除此之外,還存在 SQL86、SQL89、SQL2003、SQL2008、SQL2011,SQL2016等等。

    但對我們來說,SQL92 和 SQL99 是最常用的兩個標準,主要學習這兩個就可以了。

    為了演示方便,現在數據庫中加入如下三張表:

    每個學生屬於一個班級,通過班級的人數來對應班級的類型。

    -- ----------------------------
    DROP TABLE IF EXISTS `Student`;
    CREATE TABLE `Student` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `name` varchar(20) NOT NULL DEFAULT '',
      `birth` varchar(20) NOT NULL DEFAULT '',
      `sex` varchar(10) NOT NULL DEFAULT '',
      `class_id` int(11) NOT NULL COMMENT '班級ID',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8;
    
    -- ----------------------------
    -- Records of Student
    -- ----------------------------
    INSERT INTO `Student` VALUES ('1', '胡一', '1994.1.1', '男', '1');
    INSERT INTO `Student` VALUES ('3', '王阿', '1992.1.1', '女', '1');
    INSERT INTO `Student` VALUES ('5', '王琦', '1993.1.2', '男', '1');
    INSERT INTO `Student` VALUES ('7', '劉偉', '1998.2.2', '女', '1');
    INSERT INTO `Student` VALUES ('11', '張使', '1994.1.1', '男', '3');
    INSERT INTO `Student` VALUES ('13', '王阿', '1992.1.1', '女', '3');
    INSERT INTO `Student` VALUES ('15', '夏琪', '1993.1.2', '男', '3');
    INSERT INTO `Student` VALUES ('17', '劉表', '1998.2.2', '女', '3');
    INSERT INTO `Student` VALUES ('19', '諸葛', '1994.1.1', '男', '3');
    INSERT INTO `Student` VALUES ('21', '王前', '1992.1.1', '女', '3');
    INSERT INTO `Student` VALUES ('23', '王意識', '1993.1.2', '男', '3');
    INSERT INTO `Student` VALUES ('25', '劉等待', '1998.2.2', '女', '3');
    INSERT INTO `Student` VALUES ('27', '胡是一', '1994.1.1', '男', '5');
    INSERT INTO `Student` VALUES ('29', '王阿請', '1992.1.1', '女', '5');
    INSERT INTO `Student` VALUES ('31', '王消息', '1993.1.2', '男', '5');
    INSERT INTO `Student` VALUES ('33', '劉全', '1998.2.2', '女', '5');
    INSERT INTO `Student` VALUES ('35', '胡愛', '1994.1.1', '男', '5');
    INSERT INTO `Student` VALUES ('37', '王表', '1992.1.1', '女', '5');
    INSERT INTO `Student` VALUES ('39', '王華', '1993.1.2', '男', '5');
    INSERT INTO `Student` VALUES ('41', '劉偉以', '1998.2.2', '女', '5');
    INSERT INTO `Student` VALUES ('43', '胡一彪', '1994.1.1', '男', '5');
    INSERT INTO `Student` VALUES ('45', '王阿符', '1992.1.1', '女', '5');
    INSERT INTO `Student` VALUES ('47', '王琦刪', '1993.1.2', '男', '5');
    INSERT INTO `Student` VALUES ('49', '劉達達', '1998.2.2', '女', '5');
    
    -- ----------------------------
    -- Table structure for `Class`
    -- ----------------------------
    DROP TABLE IF EXISTS `Class`;
    CREATE TABLE `Class` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `name` varchar(20) NOT NULL DEFAULT '',
      `number` int(11) NOT NULL DEFAULT '',
      `class_type_id` int(11) NOT NULL COMMENT '班級類型ID',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
    
    -- ----------------------------
    -- Records of Class
    -- ----------------------------
    INSERT INTO `Class` VALUES ('1', '1年1班', 4, '1');
    INSERT INTO `Class` VALUES ('3', '1年2班', 8, '3');
    INSERT INTO `Class` VALUES ('5', '1年3班', 12, '5');
    
    CREATE TABLE `ClassType`(
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `name` VARCHAR(20) NOT NULL DEFAULT '',
      `minimum_number` int(11) NOT NULL DEFAULT '' COMMENT '最少的班級人數',
      `maximum_number` int(11) NOT NULL DEFAULT '' COMMENT '最多的班級人數',
      PRIMARY KEY(`id`)
    );
    INSERT INTO `ClassType` VALUES ('1', '小班', '1', '4');
    INSERT INTO `ClassType` VALUES ('3', '中班', '5', '8');
    INSERT INTO `ClassType` VALUES ('5', '大班', '9', '12');
    

    SQL92

    笛卡爾積(交叉連接)

    笛卡爾積是一個數學上的概念,表示如果存在 X,Y 兩個集合,則 X,Y 的笛卡爾積記為 X * Y. 表示由 X,Y 組成有序對的所有情況。

    對應在 SQL 中,就是將兩張表中的每一行進行組合。而且在連接時,可以沒有任何限制,可將沒有關聯關係的任意表進行連接。

    這裏拿學生表和班級表舉例,在學生表中我們插入了20名學生的數據,課程表中插入三個班級。則學生和班級的笛卡爾結果就是將兩表的每行數據一一組合,最後就是有 24 * 3 = 72 行的結果,如下圖所示。

    並且需要知道的是,下面學習的外連接,自連接,等值連接等都是在笛卡爾積的基礎上篩選得到的。

    對應的 SQL92 寫法為:

    select * from Student, Class;
    

    等值連接(內連接)

    等值連接就是將兩張表中都存在的列進行連接,具體來說就是 where 後面通過 = 進行篩選。

    比如查詢 Student 和其所屬 Class 信息的關係:

    SELECT * FROM Student as s, Class as c where s.class_id = c.id;
    

    非等值連接

    非等值連接就是將等值連接中的等號換成其他的過濾條件。

    比如這裏查詢每個班級的信息以及所屬的班級類別。

    SELECT * FROM Class as c, ClassType t where c.number between t.minimum_number and maximum_number;
    

    外連接

    對於 SQL92 的外連接來說,在連接時會將兩張表分為主表和從表,主表显示所有的數據,從表显示匹配到的數據,沒有匹配到的則显示 None. 用 + 表示從表的位置。

    左外連接:左表是主表,右表時從表。

    SELECT * FROM Student as s , Class as c where s.class_id = c.id(+);
    

    右外連接:左表是從表,右表時主表。

    SELECT * FROM Class as c, Student as s  where c.id = s.class_id(+);
    

    注意 SQL92 中並沒有全外連接。

    自連接

    自連接一般用於連接本身這張表,由於常見的 DBMS 都會對自連接做一些優化,所以一般在子查詢和自連接的情況下都使用自連接。

    比如想要查詢比1年1班人數多的班級:

    子查詢:

    SELECT * FROM Class WHERE number > (SELECT number FROM Class WHERE name="1年1班"); 
    

    自連接:

    SELECT c2.* FROM Class c1, Class c2 WHERE c1.number < c2.number and c1.name = "1年1班"; 
    

    SQL99

    交叉連接

    SELECT * FROM Student CROSS JOIN Class;
    

    還可以對多張表進行交叉連接,比如連接 Student,Class,ClassType 三張表,結果為 24 * 3 * 3 = 216 條。

    相當於嵌套了三層 for 循環。

    自然連接

    其實就是 SQL92 中的等值連接,只不過連接的對象是具有相同列名,並且值也相同的內容。

    SELECT * FROM Student NATURAL JOIN CLASS;
    
    SELECT * FROM Student as s, Class as c where s.id = c.id;
    

    如果想用 NATURAL JOIN 時,建議為兩表設置相同的列名,比如 Student 表中的班級列為 class_id, 則在 Class 表中,id 也應改為 class_id. 這樣連接更合理一些。

    如果大家嘗試,自然連接的話,會發現查出來的結果集為空,不要奇怪,下面說一下原因:

    這是因為,NATURAL JOIN 會自動連接兩張表中相同的列名,而對於 Student 和 Class 兩張表來說,id 和 name 在這兩張表都是相同的,所以既滿足 id 又滿足 name 的行是不存在的。

    相當於 SQL 變成了這樣

    SELECT * FROM Student as s, Class as c where s.id = c.id and s.name = c.name;
    

    ON 連接

    ON 連接其實對了 SQL92 中的等值連接和非等值連接:

    等值連接:

    SELECT * FROM Student as s JOIN Class as c ON s.class_id = c.id;
    
    or
    
    SELECT * FROM Student as s INNER JOIN Class as c ON s.class_id = c.id;
    

    非等值連接:

    SELECT * FROM Class as c JOIN ClassType t ON c.number between t.minimum_number and maximum_number;
    

    USING 連接

    和 NATURAL JOIN 很像,可以手動指定具有相同列名的列進行連接:

    SELECT * FROM Student JOIN Class USING(id);
    

    這時就解決了之前列存在重名,無法連接的情況。

    外連接

    左外連接: 左表是主表,右表時從表。

    SELECT * FROM Student as s LEFT JOIN Class as c on s.class_id = c.id;
    OR
    SELECT * FROM Student as s LEFT OUTER JOIN Class as c on s.class_id = c.id;
    

    右外連接:左表是從表,右表時主表。

    SELECT * FROM Student as s RIGHT JOIN Class as c on s.class_id = c.id;
    OR
    SELECT * FROM Student as s RIGHT OUTER JOIN Class as c on s.class_id = c.id;
    

    全外連接: 左外連接 + 右外的連接的合集

    SELECT * FROM Student as s FULL JOIN Class as c ON s.class_id = c.id; 
    

    MySQL 中沒有全外連接的概念。

    自連接:

    SELECT c2.* FROM Class c1 JOIN Class c2 ON c1.number < c2.number and c1.name = "1年1班"; 
    

    SQL92 和 SQL99 的對比

    1. SQL92 中的等值連接(內連接),非等值連接,自連接對應了 SQL99 的 ON 連接,用於篩選滿足連接條件的數據行。

    2. SQL92 的笛卡爾積連接,對應了 SQL99 的交叉連接。

    3. SQL92 中的外連接並不包含全外連接,而 SQL99 支持,並且將 SQL92 中 WHERE 換為 SQL99 的 ON. 這樣的好處可以更清晰的表達連接表的過程,更直觀。

      SELECT ...
      FROM table1
          JOIN table2 ON filter_condition
              JOIN table3 ON filter_condition
      
    4. SQL99 多了自然連接和 USING 連接的過程,兩者的區別是是否需要顯式的指定列名。

    總結

    我們知道,在 SQL 中,按照年份劃分了不同的標準,其中最為常用的是 SQL-92 和 SQL-99 兩個標準。

    接着,對比了 92 和 99 兩者的不同,發現 99 的標準在連接時,更加符合邏輯並且更加直觀。

    最後,上一張各種連接的示意圖, 方便梳理複習:

    參考

    各種連接的不同

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

    台北網頁設計公司這麼多該如何選擇?

    ※智慧手機時代的來臨,RWD網頁設計為架站首選

    ※評比南投搬家公司費用收費行情懶人包大公開

    ※回頭車貨運收費標準

  • 【K8S】Service服務詳解,看這一篇就夠了!!

    k8s用命名空間namespace把資源進行隔離,默認情況下,相同的命名空間里的服務可以相互通訊,反之進行隔離。

    1.1 Service

    Kubernetes中一個應用服務會有一個或多個實例(Pod,Pod可以通過rs進行多複本的建立),每個實例(Pod)的IP地址由網絡插件動態隨機分配(Pod重啟后IP地址會改變)。為屏蔽這些後端實例的動態變化和對多實例的負載均衡,引入了Service這個資源對象,如下所示:

    apiVersion: v1
    kind: Service
    metadata:
      name: nginx-svc
      labels:
        app: nginx
    spec:
      type: ClusterIP
      ports:
        - port: 80
           targetPort: 80
      selector:  #service通過selector和pod建立關聯
        app: nginx

    根據創建Service的type類型不同,可分成4種模式:

    • ClusterIP: 默認方式。根據是否生成ClusterIP又可分為普通Service和Headless Service兩類:
      • 普通Service:通過為Kubernetes的Service分配一個集群內部可訪問的固定虛擬IP(Cluster IP),實現集群內的訪問。為最常見的方式。
      • Headless Service:該服務不會分配Cluster IP,也不通過kube-proxy做反向代理和負載均衡。而是通過DNS提供穩定的絡ID來訪問,DNS會將headless service的後端直接解析為podIP列表。主要供StatefulSet使用。
    • NodePort:除了使用Cluster IP之外,還通過將service的port映射到集群內每個節點的相同一個端口,實現通過nodeIP:nodePort從集群外訪問服務。
    • LoadBalancer:和nodePort類似,不過除了使用一個Cluster IP和nodePort之外,還會向所使用的公有雲申請一個負載均衡器(負載均衡器後端映射到各節點的nodePort),實現從集群外通過LB訪問服務。
    • ExternalName:是 Service 的特例。此模式主要面向運行在集群外部的服務,通過它可以將外部服務映射進k8s集群,且具備k8s內服務的一些特徵(如具備namespace等屬性),來為集群內部提供服務。此模式要求kube-dns的版本為1.7或以上。這種模式和前三種模式(除headless service)最大的不同是重定向依賴的是dns層次,而不是通過kube-proxy。
      比如,在service定義中指定externalName的值”my.database.example.com”:

    此時k8s集群內的DNS服務會給集群內的服務名 ..svc.cluster.local 創建一個CNAME記錄,其值為指定的”my.database.example.com”。
    當查詢k8s集群內的服務my-service.prod.svc.cluster.local時,集群的 DNS 服務將返回映射的CNAME記錄”foo.bar.example.com”。

    備註: 前3種模式,定義服務的時候通過selector指定服務對應的pods,根據pods的地址創建出endpoints作為服務後端;Endpoints Controller會watch Service以及pod的變化,維護對應的Endpoint信息。kube-proxy根據Service和Endpoint來維護本地的路由規則。當Endpoint發生變化,即Service以及關聯的pod發生變化,kube-proxy都會在每個節點上更新iptables,實現一層負載均衡。 而ExternalName模式則不指定selector,相應的也就沒有port和endpoints。 ExternalName和ClusterIP中的Headles Service同屬於Headless Service的兩種情況。Headless Service主要是指不分配Service IP,且不通過kube-proxy做反向代理和負載均衡的服務。

    1.2 Port

    Service中主要涉及三種Port: * port 這裏的port表示service暴露在clusterIP上的端口,clusterIP:Port 是提供給集群內部訪問kubernetes服務的入口。

    • targetPort

    containerPort,targetPort是pod上的端口,從port和nodePort上到來的數據最終經過kube-proxy流入到後端pod的targetPort上進入容器。

    • nodePort

    nodeIP:nodePort 是提供給從集群外部訪問kubernetes服務的入口。

    總的來說,port和nodePort都是service的端口,前者暴露給從集群內訪問服務,後者暴露給從集群外訪問服務。從這兩個端口到來的數據都需要經過反向代理kube-proxy流入後端具體pod的targetPort,從而進入到pod上的容器內。

    1.3 IP

    使用Service服務還會涉及到幾種IP:

    • ClusterIP

    Pod IP 地址是實際存在於某個網卡(可以是虛擬設備)上的,但clusterIP就不一樣了,沒有網絡設備承載這個地址。它是一個虛擬地址,由kube-proxy使用iptables規則重新定向到其本地端口,再均衡到後端Pod。當kube-proxy發現一個新的service后,它會在本地節點打開一個任意端口,創建相應的iptables規則,重定向服務的clusterIP和port到這個新建的端口,開始接受到達這個服務的連接。

    • Pod IP

    Pod的IP,每個Pod啟動時,會自動創建一個鏡像為gcr.io/google_containers/pause的容器,Pod內部其他容器的網絡模式使用container模式,並指定為pause容器的ID,即:network_mode: “container:pause容器ID”,使得Pod內所有容器共享pause容器的網絡,與外部的通信經由此容器代理,pause容器的IP也可以稱為Pod IP。

    • 節點IP

    Node-IP,service對象在Cluster IP range池中分配到的IP只能在內部訪問,如果服務作為一個應用程序內部的層次,還是很合適的。如果這個service作為前端服務,準備為集群外的客戶提供業務,我們就需要給這個服務提供公共IP了。指定service的spec.type=NodePort,這個類型的service,系統會給它在集群的各個代理節點上分配一個節點級別的端口,能訪問到代理節點的客戶端都能訪問這個端口,從而訪問到服務。

     

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

    南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

    ※教你寫出一流的銷售文案?

    ※超省錢租車方案

  • 龍芯團隊完成CoreCLR MIPS64移植,已在github開源

    龍芯團隊完成CoreCLR MIPS64移植,已在github開源

    國產龍芯的軟件生態之中.NET不會缺席,畢竟 C# 與 .NetCore/Mono 也是全球幾大主流的編程語言和運行平台之一,最近一段時間聽到太多的鼓吹政務領域不支持.NET, 大家都明白這是某些人為了自己的利益打壓使用.NET技術的公司,我今天寫這篇文章就是想通過龍芯團隊的行動告訴更多人一起來推動.NET技術在中國的發展。希望龍芯廠商、支持龍芯的國產操作系統廠商能高度重視這個問題,主動加入 .Net Core 社區,加入.NET基金會,积極貢獻代碼,儘快做好適配工作。

    龍芯團隊一直在做net core的mips64移植工作,2020年6月18日完成了里程碑性的工作,在.NET Core 3.1分支上完成了MIPS64 的移植工作,目前已經在github上開源,開源地址:https://github.com/gsvm/coreclr 。具體說明可以參見 https://github.com/dotnet/runtime/issues/38069。 龍芯團隊正在做移植后的測試工作,已經完成了 9500 多項測試,ASP.NET Core示例程序 FlightFinder 已經可以在MIPS64 上正常運行,具體可以參看 https://github.com/dotnet/runtime/issues/4234。

    龍芯團隊還在github上面為龍芯.NET 建立了一個倉庫 https://github.com/gsvm/loongson-dotnet,用於關於龍芯的.NET信息,工作和下載,開源協議採用和.NET Core一樣的MIT協議。 根據這個倉庫的信息,龍芯團隊將在不久的將來發布.NET Core 3.1版本,然後升級到https://github.com/dotnet/runtime ,也就是.NET 5了。目前這項工作正在緊鑼密鼓的進行,非常歡迎大家的積极參与貢獻,包括issue或者PR,如果您有任何問題或需要任何支持,請隨時提交問題或通過电子郵件:aoqi@loongson.cn 與龍芯團隊聯繫。

    在文章的最後,我向你分享一個龍芯團隊成員 xiangzhai 在這個 https://github.com/xiangzhai/mono/issues/2 提到了指令集相關的編程的一些相關知識:

    OpenJDK、CorelCLR、mono都太大了,比較小的虛擬機例子可以看看PSP模擬器: https://github.com/xiangzhai/ppsspp-jit-mips64/commits/mips64-port-dev

    CoreCLR官方的文檔不錯:下降、寄存器分配、代碼生成 https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/jit/ryujit-overview.md

    CoreCLR代碼生成常用調試方法: dotnet/runtime#606

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    網頁設計公司推薦不同的風格,搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    網頁設計最專業,超強功能平台可客製化

  • HTTP Request Smuggling 請求走私

    HTTP Request Smuggling 請求走私

    參考文章

    淺析HTTP走私攻擊
    SeeBug-協議層的攻擊——HTTP請求走私
    HTTP 走私漏洞分析
    HTTP-Request-Smuggling

    簡單介紹

    攻擊者通過構造特殊結構的請求,干擾網站服務器對請求的處理,從而實現攻擊目標

    前提知識

    注:以下文章中的前端指的是(代理服務器、CDN、WAF,負載均衡,Nginx,HAproxy等)

    Persistent Connection:持久連接,Connection: keep-alive
    比如打開一個網頁,我們可以在瀏覽器控制端看到瀏覽器發送了許多請求(HTML、圖片、css、js),而我們知道每一次發送HTTP請求需要經過 TCP 三次握手,發送完畢又有四次揮手。當單個用戶同時需要發送多個請求時,這一點消耗或許微不足道,但當有許多用戶同時發起請求的時候,便會給服務器造成很多不必要的消耗。為了解決這一問題,在 HTTP 協議中便新加了 Connection: keep-alive 這一個請求頭,當有些請求帶着 Connection: close 的話,通信完成之後,服務器才會中斷 TCP 連接。如此便解決了額外消耗的問題,但是服務器端處理請求的方式仍舊是請求一次響應一次,然後再處理下一個請求,當一個請求發生阻塞時,便會影響後續所有請求,為此 Pipelining 異步技術解決了這一個問題

    Pipelining:能一次處理多個請求,客戶端不必等到上一個請求的響應后再發送下一個請求。服務器那邊一次可以接收多個請求,需要遵循先入先出機制,將請求和響應嚴格對應起來,再將響應發送給客戶端

    但是這樣也會帶來一個問題————如何區分每一個請求才不會導致混淆————前端與後端必須短時間內對每個數據包的邊界大小達成一致。否則,攻擊者就可以構造發送一個特殊的數據包發起攻擊。那麼如何界定數據包邊界呢?
    有兩種方式: Content-LengthTransfer-Encoding.

    Content-Length:CL,請求體或者響應體長度(十進制)。字符算一個,CRLF(一個換行)算兩個。通常如果 Content-Length 的值比實際長度小,會造成內容被截斷;如果比實體內容大,會造成 pending,也就是等待直到超時。

    Transfer-Encoding:TE,其只有一個值 chunked (分塊編碼)。分塊編碼相當簡單,在頭部加入 Transfer-Encoding: chunked 之後,就代表這個報文採用了分塊編碼。這時,報文中的實體需要改為用一系列分塊來傳輸。每個分塊包含十六進制的長度值和數據,長度值獨佔一行,長度不包括它結尾的 CRLF(\r\n),也不包括分塊數據結尾的 CRLF,但是包括分塊中的換行,值算2。最後一個分塊長度值必須為 0,對應的分塊數據沒有內容,表示實體結束。
    例如:

    POST /langdetect HTTP/1.1
    Host: fanyi.baidu.com
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 93
    Transfer-Encoding: chunked
    
    2;逗號後面是註釋
    qu
    3;3表示後面的字符長度為3(十六進制),不算CRLF(\r\n回車換行)
    ery
    1
    =
    2
    ja
    2
    ck
    0;0表示實體結束
    
    
    

    注:根據 RFC 標準,如果接收到的消息同時具有傳輸編碼標頭字段和內容長度標頭字段,則必須忽略內容長度標頭字段,當然也有不遵循標準的例外。

    根據標準,當接受到如 Transfer-Encoding: chunked, error 有多個值或者不識別的值時的時候,應該返回 400 錯誤。但是有一些方法可以繞過
    (導致既不返回400錯誤,又可以使 Transfer-Encoding 標頭失效):

    Transfer-Encoding: xchunked
    
    Transfer-Encoding : chunked
    
    Transfer-Encoding: chunked
    
    Transfer-Encoding: x
    
    Transfer-Encoding:[tab]chunked
    
    GET / HTTP/1.1
     Transfer-Encoding: chunked
    X: X[\n]Transfer-Encoding: chunked
    
    Transfer-Encoding
     : chunked
    

    產生原因

    HTTP規範提供了兩種不同方式來指定請求的結束位置,它們是 Content-Length 標頭和 Transfer-Encoding 標頭。當前/後端對數據包邊界的校驗不一致時,
    使得後端將一個惡意的殘缺請求需要和下一個正常的請求進行拼接,從而吞併了其他用戶的正常請求。如圖:

    那麼前/後端校驗不一致有那些情況呢呢呢呢?

    類型

    1. CL-TE: 前端: Content-Length,後端: Transfer-Encoding

    BURP實驗環境

    第一次請求:

    第二次請求:

    原理:前端服務器通過 Content-Length 界定數據包邊界,檢測到數據包無異常通過,然後傳輸到後端服務器,後端服務器通過 Transfer-Encoding 界定數據包邊界,導致 R0oKi3 字段被識別為下一個數據包的內容,而被送到了緩衝區,由於內容不完整,會等待後續數據,當正常用戶的請求傳輸到後端時,與之前滯留的惡意數據進行了拼接,組成了 R0OKI3POST ,為不可識別的請求方式,導致403。

    1. TE-CL: 前端: Transfer-Encoding,後端: Content-Length

    BURP實驗環境
    記得關 burp 的 Update Content-Length 功能

    第一次請求:

    第二次請求:

    原理:跟 CL-TE 相似

    1. TE-TE: 前端: Transfer-Encoding,後端: Transfer-Encoding

    BURP實驗環境
    記得關 burp 的 Update Content-Length 功能

    第一次請求:

    第二次請求:

    原理:前端服務器通過第一個 Transfer-Encoding 界定數據包邊界,檢測到數據包無異常通過,然後傳輸到後端服務器,後端服務器通過第二個 Transfer-Encoding 界定數據包邊界,結果為一個不可識別的標頭,然後便退而求其次使用 Content-Length 校驗,結果就跟 TE-CL 形式無異了。同樣若是前端服務器校驗第二個,後端服務器校驗第一個,那結果也就跟 CL-TE 形式無異了。

    1. CL-CL: 前端: Content-Length,後端: Content-Length

    在RFC7230規範中,規定當服務器收到的請求中包含兩個 Content-Length,而且兩者的值不同時,需要返回400錯誤。但難免會有服務器不嚴格遵守該規範。假設前端和後端服務器都收到該類請求,且不報錯,其中前端服務器按照第一個Content-Length的值對請求進行為數據包定界,而後端服務器則按照第二個Content-Length的值進行處理。

    這時攻擊者可以惡意構造一個特殊的請求:

    POST / HTTP/1.1
    Host: example.com
    Content-Length: 11
    Content-Length: 5
    
    123
    R0oKi3
    

    原理:前端服務器獲取到的數據包的長度11,由此界定數據包邊界,檢測到數據包無異常通過,然後傳輸到後端,而後端服務器獲取到的數據包長度為5。當讀取完前5個字符后,後端服務器認為該請求已經讀取完畢。便去識別下一個數據包,而此時的緩衝區中還剩下 R0oKi3,它被認為是下一個請求的一部分,由於內容不完整,會等待後續數據,當正常用戶的請求傳輸到後端時,與之前滯留的惡意數據進行了拼接,攻擊便在此展開。

    1. CL 不為 0 的 GET 請求:

    假設前端服務器允許 GET 請求攜帶請求體,而後端服務器不允許 GET 請求攜帶請求體,它會直接忽略掉 GET 請求中的 Content-Length 頭,不進行處理。這就有可能導致請求走私。
    比如發送下面請求:

    GET / HTTP/1.1
    Host: example.com
    Content-Length: 72
    
    POST /comment HTTP/1.1
    Host: example.com
    Content-Length:666
    
    msg=aaa
    

    前端服務器通過讀取Content-Length,確認這是個完整的請求,然後轉發到後端服務器,而後端服務器因為不對 Content-Length 進行判斷,於是在後端服務器中該請求就變成了兩個:
    第一個:

    GET / HTTP/1.1
    Host: example.com
    Content-Length: 72
    

    第二個:

    POST /comment HTTP/1.1
    Host: example.com
    Content-Length:666
    
    msg=aaa
    

    而第二個為 POST 請求,假定其為發表評論的數據包,再假定後端服務器是依靠 Content-Length 來界定數據包的,那麼由於數據包長度為 666,那麼便會等待其他數據,等到正常用戶的請求包到來,便會與其拼接,變成 msg=aaa……………… ,然後會將显示在評論頁面,也就會導致用戶的 Cookie 等信息的泄露。

    PortSwigger 其他實驗

    1. 使用 CL-TE 繞過前端服務器安全控制

    BURP實驗環境
    坑點:有時候實體數據里需要添加一些別的字段或者空行,不然會出一些很奇怪的錯誤,所以我在弄的時候參照了seebug 404Team
    實驗要求:獲取 admin 身份並刪除 carlos 用戶

    第一步:實驗提示我們 admin 管理面版在 /admin 目錄下,直接訪問,显示:

    第二步:利用 CL-TE 請求走私繞過前端服務器安全控制

    • 第一次發包

    坑點:數據實體一定要多一些其他字段或者多兩行空白,不然報 Invalid request 請求不合法

    0
    
    GET /admin HTTP/1.1
    
    
    # 若是多了兩行空白,那麼 foo: bar 字段可以不要
    

    提示 admin 要從 localhost 登陸

    • 改包后多發幾次得到

    • 改包刪除用戶

    • 再次請求 /admin 頁面,發現 carlos 用戶已不存在

      坑點:這裏再次請求的時候記得多加兩個空行改變一下 Content-Length 的值,不然會显示不出來,神奇 BUG?

    原理:網站進行身份驗證的處理是在前端服務器,當直接訪問 /admin 目錄時,由於通過不了前端驗證,所以會返回 Blocked。利用請求走私,便可以繞過前端驗證,直接在後端產生一個訪問 /admin 目錄的請求包,當發起下一個請求時,響應的數據包對應的是走私的請求包,如此便可以查看 admin 面板的頁面數據,從而達到繞過前端身份驗證刪除用戶的目的。

    1. 使用 TE-CL 繞過前端服務器安全控制

    BURP實驗環境

    實驗過程與上一個實驗相仿,不過要記得關 burp 的 Update Content-Length

    這裏:不知道為什麼一定要加 Content-Length 和其他的一些詞,不加的話會显示 Invalid request 請求不合法 ?????????

    1. 獲取前端服務器重寫請求字段(CL-TE)

    BURP實驗環境

    摘自seebug 404Team
    在有的網絡環境下,前端代理服務器在收到請求后,不會直接轉發給後端服務器,而是先添加一些必要的字段,然後再轉發給後端服務器。這些字段是後端服務器對請求進行處理所必須的,比如:

    • 描述TLS連接所使用的協議和密碼

    • 包含用戶IP地址的XFF頭

    • 用戶的會話令牌ID
      總之,如果不能獲取到代理服務器添加或者重寫的字段,我們走私過去的請求就不能被後端服務器進行正確的處理。那麼我們該如何獲取這些值呢。PortSwigger提供了一個很簡單的方法,主要是三大步驟:

    • 找一個能夠將請求參數的值輸出到響應中的POST請求

    • 把該POST請求中,找到的這個特殊的參數放在消息的最後面

    • 然後走私這一個請求,然後直接發送一個普通的請求,前端服務器對這個請求重寫的一些字段就會显示出來。

    • 第一步:找一個能夠將請求參數的值輸出到響應中的POST請求

    • 第二步:利用 CL-TE 走私截獲正常數據包經前端服務器修改后發送過來的內容,並輸出在響應包中

    這一步的原理:由於我們走私構造的請求包為:

    POST / HTTP/1.1
    Content-Length: 100
    
    search=66666
    

    從這裏可以看到,Content-Length 的值為 100,而我們的實體數據僅為 search=66666,遠沒有 100,於是後端服務器便會進入等待狀態,當下一個正常請求到來時,會與之前滯留的請求進行拼接,從而導致走私的請求包吞併了下一個請求的部分或全部內容,並返回走私請求的響應。

    • 第三步:在走私的請求上添加這個字段,然後走私一個刪除用戶的請求。

    • 查看 /admin 頁面,發現用戶已被刪除

    能用來干什麼

    1. 賬戶劫持 CL-TE
      BURP實驗環境
    • 構造特殊請求包,形成一個走私請求

    • 查看評論

    原理:(跟 獲取前端服務器重寫請求字段 相似)
    我們走私構造的請求包為:

    POST /post/comment HTTP/1.1
    Host: aca41ff41e89d28f800d3e82001a00c8.web-security-academy.net
    Content-Length: 900
    Cookie: session=XPbI3LJQJCoBcQOvsLdfyCNbOKqsGudy
    
    csrf=Nk6OsCxcNIUdfnrpQuy9N3WO0zLLcAWU&postId=4&name=aaa&email=aaa%40aaa.com&website=&comment=aaaa
    
    
    

    可以看到 Content-Length 值為 900,而我們的實體數據僅為 csrf=Nk6OsCxcNIUdfnrpQuy9N3WO0zLLcAWU&postId=4&name=aaa&email=aaa%40aaa.com&website=&comment=aaaa,遠不足900,於是後端服務器便會進入等待狀態,當下一個正常請求到來時,會與之前滯留的請求進行拼接,從而導致走私的請求包吞併了下一個請求的部分或全部內容,並且由於是構造發起評論的請求包,所以數據會存入數據庫,從而打開頁面便會看到其他用戶的請求包內容,獲取其敏感數據,由於環境只有我一個人在玩,所以只能獲取到自己的敏感數據。

    注意:一定要將 comment=aaaa 放在最後

    1. Reflected XSS + Smuggling 造成無需交互的 XSS(CL-TE)
      BURP實驗環境
    • 首先反射型 XSS 在文章頁面

    • 構造請求走私 payload

    • 導致無交互 XSS

    1. 惡意重定向
      環境暫無

    許多應用程序執行從一個 URL 到另一個URL的重定向,會將來自請求的 Host 標頭的主機名放入重定向URL。一個示例是 Apache 和 IIS Web 服務器的默認行為,在該行為中,對不帶斜杠的文件夾的請求將收到對包含該斜杠的文件夾的重定向:

    請求
    GET /home HTTP/1.1
    Host: normal-website.com
    
    響應
    HTTP/1.1 301 Moved Permanently
    Location: https://normal-website.com/home/
    

    通常,此行為被認為是無害的,但是可以在走私請求攻擊中利用它來將其他用戶重定向到外部域。例如:

     POST / HTTP/1.1
    Host: vulnerable-website.com
    Content-Length: 54
    Transfer-Encoding: chunked
    
    0
    
    GET /home HTTP/1.1
    Host: attacker-website.com
    Foo: X 
    

    走私的請求將觸發重定向到攻擊者的網站,這將影響後端服務器處理的下一個用戶的請求。例如:

    正常請求
    GET /home HTTP/1.1
    Host: attacker-website.com
    Foo: XGET /scripts/include.js HTTP/1.1
    Host: vulnerable-website.com
    
    惡意響應
    HTTP/1.1 301 Moved Permanently
    Location: https://attacker-website.com/home/ 
    

    若用戶請求的是一個 JavaScript 文件,該文件是由網站上的頁面導入的。攻擊者可以通過在響應中返回自己的 JavaScript 文件來完全破壞受害者用戶。

    4.緩存投毒

    一般來說,前端服務器出於性能原因,會對後端服務器的一些資源進行緩存,如果存在HTTP請求走私漏洞,則有可能使用重定向來進行緩存投毒,從而影響後續訪問的所有用戶。

    BURP實驗環境

    實驗參考

    檢測

    檢測請求走私漏洞的明顯方法是發出一個模糊的請求,然後發出正常的“受害者”請求,然後觀察後者是否得到意外的響應。但是,這極易受到干擾。

    如果另一個用戶的請求在我們的受害者請求之前命中,他們將得到損壞的響應,我們將不會發現該漏洞。這意味着在具有大量流量的實時站點上,很難證明請求走私存在而不會在此過程中影響眾多真正的用戶。即使在沒有其他流量的站點上,您也可能會因應用程序級別的怪癖終止連接而導致漏報。

    為了解決這個問題,作者開發了一種檢測策略,該策略使用一系列消息,這些消息使易受攻擊的後端系統掛起並使連接超時。這種技術幾乎沒有誤報,抵制應用程序級別的怪癖,最重要的是幾乎沒有影響其他用戶的風險。

    假設前端服務器使用Content-Length頭,後端使用Transfer-Encoding頭。我將此定位稱為CL.TE。我們可以通過發送以下請求來檢測潛在的請求走私:

    POST / HTTP/1.1
    Host: example.com
    Content-Length: 4
    Transfer-Encoding: chunked
    
    1
    R
    x
    

    由於較短的Content-Length,前端將僅轉發到 R 丟棄後續的 X,而後端將在等待下一個塊大小時超時。這將導致明顯的時間延遲。
    如果超時說明兩個服務器為CL.TE,正常響應就是CL.CL,被拒絕就可能是TE.TE或者TE.CL,那麼只需要在拒絕的時候,再使用第二個請求,TE.TE就會正常響應,TE.CL就會超時。

    如果兩個服務器同步(TE.TE或CL.CL),請求將被前端拒絕或由兩個系統無害地處理。最後,如果以相反的方式發生(TE.CL),前端將拒絕該消息,而不會將其轉發到後端,這要歸功於無效的塊大小“Q”。這可以防止後端中毒。

    我們可以使用以下請求安全地檢測TE.CL:

    POST / HTTP/1.1
    Host: example.com
    Content-Length: 6
    Transfer-Encoding: chunked
    
    0
    
    
    X
    

    如果以相反的方式發生(CL.TE),則此方法將使用X毒化後端套接字,可能會損害合法用戶。幸運的是,通過首先運行先前的檢測方法,我們可以排除這種可能性。

    這些請求可以適應目標解析中的任意差異,並且它們用於通過HTTP Request Smuggler自動識別請求走私漏洞。HTTP Request Smuggler是為幫助此類攻擊而開發的開源Burp Suite擴展。它們現在也被用在Burp Suite的核心掃描儀中。雖然這是服務器級漏洞,但單個域上的不同接口通常會路由到不同的目標,因此應將此技術單獨應用於每個接口。

    修復

    1. 禁用後端連接的重用,以便每個後端請求通過單獨的網絡連接發送。
    2. 使用HTTP / 2進行後端連接,因為此協議可防止對請求之間的邊界產生歧義。
    3. 前端服務器和後端服務器使用完全相同的Web服務器軟件,以便它們就請求之間的界限達成一致。
      以上的措施有的不能從根本上解決問題,而且有着很多不足,就比如禁用代理服務器和後端服務器之間的 TCP 連接重用,會增大後端服務器的壓力。使用 HTTP/2 在現在的網絡條件下根本無法推廣使用,哪怕支持 HTTP/2 協議的服務器也會兼容 HTTP/1.1。從本質上來說,HTTP 請求走私出現的原因並不是協議設計的問題,而是不同服務器實現的問題,個人認為最好的解決方案就是嚴格的實現 RFC7230-7235 中所規定的的標準,但這也是最難做到的。

    HTTP 參數污染也能算是一種請求走私 HTTP參數污染

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※帶您來了解什麼是 USB CONNECTOR  ?

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    ※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!

    ※綠能、環保無空污,成為電動車最新代名詞,目前市場使用率逐漸普及化

    ※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

    ※教你寫出一流的銷售文案?

  • 如何提升自己?

    如何提升自己?

    如何提升自己?

    看完後浪,感慨良多…

    在程序員圈子,聽得最多的便是”35歲中年危機“。

    危機

    其實不僅僅存在“35歲危機”,還有“畢業危機”,“被裁員危機”,不僅僅在程序員圈子,幾乎所有圈子都是這樣,就像剛畢業的大學生說的:畢業等於失業。現在的社會飛速發展,我們常常感嘆大多數父母一代的人,智能手機玩着都比較費勁,其實也算是一種危機。其實不管任何職業,任何年齡的人,都應該保持“學習”的狀態,只有自身有了底氣,才能挺直了腰板,度過一個又一個危機。恩,做的不開心,我就換個工作…厲害的人,都是別人來請他去上班的。

    作為一個Javaer,當然也需要不斷的保持學習,特別是對於剛畢業的人,可能在找第一份工作的時候,你大廠與你擦肩而過,但是只要你對未來有一個完整的規劃,3年後,你一樣能達到你的目標。

    說了這麼多,只是為了強調學習的重要性。但是如何學習?學習什麼?這才是真正的問題。

    如何學習?

    很多人喜歡看視頻學習,記得剛學Java的時候,很多同學都會去看馬士兵,傳智博客等等。。。的確,視頻適合帶你入門,但是卻不適合進階。

    如果你是一個什麼都不知道的小白, 不知道什麼是IDE,是什麼叫配置環境變量,那麼的確可以看看視頻學習,因為它能帶你很快的上手,避免走很多坑。

    但是如果你是一個有一點項目經驗的人,那麼個人是不推薦通過視頻來學習新的知識的。第一個便是因為資源太少。除了培訓機構和各種專門為了做教育行業的人,很少有其他人會專門通過視頻介紹技術,即使有,視頻質量也難以得到保障。第二個便是效率問題,看視頻你不敢跳過,害怕錯過知識點,你也更加容易走神,因為進度掌握在別人手裡。

    所以最好的學習方式便是看資料,比如看書,看官方文檔等。

    如何看書?

    書讀百遍,其義自見。能真正把一本書看很多遍的人,一定能體會到這句話的精髓所在。

    擁有不同知識的人,看一本書的收貨一定是不一樣的。這裏可以簡單舉一個例子:一個剛學完Java基礎知識的人,看《Effective Java》的時候,可能只會死記硬背。一個擁有三年開發經驗的人,看《Effectice Java》的時候,會覺得恍然大悟。而一個擁有豐富的開發經驗的人,看《Effective Java》的時候,一定會激動的拍打着桌子:“對,當時這個坑就是這樣的”。

    當你想要了解一個知識點的時候,比如JVM,你可以先去各個網站,找一找網友推薦的書,一般比較經典的技術,都會有一本比較經典的書。比如JVM中的《深入理解Java虛擬機》。記住,如果是想深入了解的話,一定要買好書,湊字數的書,只適合你看個大概。

    挑選好一本書後,首先應該查看書的前言,然後看看目錄,了解整本書得框架以及知識點的分佈。最好帶着問題去看書。比如你看JVM,可能就是想了解大家常說的GC,JVM內存分佈,JVM調優等等,明白這些問題在書的第幾節,想想作者為什麼要把這個問題安排在這個地方?想要解答這些問題,需要明白哪些前提條件?

    做完上面的步驟后,就可以開始看書了,看一個好書,我建議一遍泛讀,兩遍精讀,三遍薄讀。

    第一遍,快速閱覽這本書,但是每個地方都要留一個印象,有問題不用怕,記在心裏。明白書的大體講了什麼,側重講了什麼,哪些是重點。更加重要的是,你在快速閱覽過程中,產生了什麼問題。

    當看完第一遍后,我不太建議立即去看第二遍,看完第一遍,應該對整個技術有個大概的了解,這個時候你應該實際去上手去做,比如JVM打打日誌看看,jps.exe,jstat.exe等調試工具用一用看看,嘗試將書中的內容應用到實際中。這個時候,你會產生更多的問題。

    第二遍,當經過一定的上手后,這個時候你就可以去看第二遍了,看第二遍的時候,心裏應該明白,你想解決什麼問題,你應該重點看哪裡。看的過程中,多想一想為什麼?想不明白的,一定上網查一查,問一問。這個過程中,其實更加推薦的是寫讀書筆記或者博客。嘗試將自己學到的東西講給別人聽,你會有意想不到的收穫。

    當看完第二遍后,就可以暫時休息了,因為一本書,寫的再好,看兩遍都會有點乏味,看完這遍后,整理下知識點,簡單回顧下。

    第三遍,第三遍應該在時間過去比較久之後再看,這一邊的速度可以很快,主要目的就是檢查你對這本書的內容的記憶程度理解的再好,都有可能會忘。每看到一部分內容,就去回想一下這部分內容的重點是什麼?有什麼值得注意的?為什麼是這樣。當你發現你都能說出來時,這本就,就已經薄成一張紙了、

    看哪些書?

    明白了怎麼看書之後,最後一個問題便是看哪些書了…

    作為一個程序員,最重要的便是基礎。基礎不牢,地動山搖。技術的迭代是非常快的,前幾年大火的C#,如今在國內需求已經比較少了,再比如現在慢慢崛起的go,想要不被時代拋棄,必須學會快速掌握一個新的知識,而這些知識其實都萬變不離其中。那便是基礎。

    掌握操作系統,能讓你快速明白JVM,多線程,NIO,零拷貝原理等。

    掌握網絡基礎,能讓你快速明白HttpSocketHttps

    當然,這裏所說的基礎,也包括一本語言的基礎,比如Java開發基礎等。

    等有了這些基礎知識,再去學習整體開發的框架,會事半功倍。

    明白了基礎的重要性,剩下的就是掌握一個高級開發工程師應該掌握的技能。

    然而,什麼才是一個高級開發工程師應該掌握的技能?

    很遺憾,我不能告訴你。因為不同方向,不同企業,不同部門,不同的業務。對一個人技能的要求,是不一樣的。

    最好的方法便是定製一個目標,然後看看你離這個目標還有多遠。

    怎麼去衡量你離這個目標還有多遠呢?最好的答案便是面試。面試犹如考試,少看哪些博眼球的文章標題為面試官問我…,製造焦慮,太偏的知識點可以簡單了解,但是別太浪費時間。不管你有沒有準備好,現在開始,準備一份你的簡歷,找一些差不多的崗位,然後接受面試官的鞭撻。總結每一次面試中,你發現你有空白的知識點,然後找一本書,看它。不用害怕簡歷沒什麼寫的,沒什麼寫的簡歷,更應該開始着手準備,機會總是給有準備的人。

    堅持上面我說的,我相信,offer會比“危機”先到一步。

    有感而發,隨便寫寫。

    —— 胖毛2020/06/19

    個人公眾號,隨便寫寫

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※為什麼 USB CONNECTOR 是電子產業重要的元件?

    網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※台北網頁設計公司全省服務真心推薦

    ※想知道最厲害的網頁設計公司"嚨底家"!

    ※推薦評價好的iphone維修中心