趣味新聞網 logo



這個是一個不容易被注意到的問題 但是使用 MongoDB 時一定要注意的就是避免任何查詢的內存操作 MongoDB 全方位知識圖譜 - 趣味新聞網


這個是一個不容易被注意到的問題 但是使用 MongoDB 時一定要注意的就是避免任何查詢的內存操作 MongoDB 全方位知識圖譜


發表日期 2022-04-02 18:46



     趣味新聞網記者特別報導 : 這個是一個不容易被注意到的問題,但是使用 MongoDB 時一定要注意的就是避免任何查詢的內存操作,因為用 MongoDB 的很多場景都是海量數據,這個情況下任何內存操作的成本都可能是非常高昂甚至會搞 .....


    

原標題:MongoDB 全方位知識圖譜

MongoDB 全方位知識圖譜

作者:sakychen,騰訊 CSIG 後台開發工程師

MongoDB 是一個強大的分布式存儲引擎,天然支持高可用、分布式和靈活設計。MongoDB 的一個很重要的設計理念是:服務端隻關注底層核心能力的輸齣,至於怎麼用,就盡可能的將工作交個客戶端去決策。這也就是 MongoDB 靈活性的保證,但是靈活性帶來的代價就是使用成本的提升。與 MySql 相比,想要用好 MongoDB,減少在項目中齣問題,用戶需要掌握的東西更多。本文緻力於全方位的介紹 MongoDB 的理論和應用知識,目標是讓大傢可以通過閱讀這篇文章之後能夠掌握 MongoDB 的常用知識,具備在實際項目中高效應用 MongoDB 的能力。

本文既有 MongoDB 基礎知識也有相對深入的進階知識,同時適用於對 MonogDB 感興趣的初學者或者希望對 MongoDB 有更深入瞭解的業務開發者。

前言

以下是筆者在學習和使用 MongoDB 過程中總結的 MongoDB 知識圖譜。本文將按照一下圖譜中依次介紹 MongoDB 的一些核心內容。由於能力和篇幅有限,本文並不會對圖譜中全部內容都做深入分析,後續將會針對特定條目做專門的分析。同時,如果圖譜和內容中有錯誤或疏漏的地方,也請大傢隨意指正,筆者這邊會積極修正和完善。

本文按照圖譜從以下 3 個方麵來介紹 MongoDB 相關知識:

第一部分:基礎知識

MongoDB 是基於文檔的 NoSql 存儲引擎。MongoDB 的數據庫管理由數據庫、Collection(集閤,類似 MySql 的錶)、Document(文檔,類似 MySQL 的行)組成,每個 Document 都是一個類 JSON 結構 BSON 結構數據。

MongoDB 的核心特性是:No Schema、高可用、分布式(可平行擴展),另外 MongoDB 自帶數據壓縮功能,使得同樣的數據存儲所需的資源更少。本節將會依次介紹這些特性的基本知識,以及 MongoDB 是如何實現這些能力的。

1.1 No Schema

MongoDB 是文檔型數據庫,其文檔組織結構是 BSON(Binary Serialized Document Format) 是類 JSON 的二進製存儲格式,數據組織和訪問方式完全和 JSON 一樣。支持動態的添加字段、支持內嵌對象和數組對象,同時它也對 JSON 做瞭一些擴充,如支持 Date 和 BinData 數據類型。正是 BSON 這種字段靈活管理能力賦予瞭 Mongo 的 No Schema 或者 Schema Free 的特性。

No Schema 特性帶來的好處包括:

  • 強大的錶現能力:對象嵌套和數組結構可以讓數據庫中的對象具備更高的錶現能力,能夠用更少的數據對象錶現復雜的領域模型對象。
  • 便於開發和快速迭代:靈活的字段管理,使得項目迭代新增字段非常容易
  • 降低運維成本:數據對象結構變更不需要執行 DDL 語句,降低 Online 環境的數據庫操作風險,特彆是在海量數據分庫分錶場景。MongoDB 在提供 No Schema 特性基礎上,提供瞭部分可選的 Schema 特性:Validation。其主要功能有包括:
  • 規定某個 Document 對象必須包含某些字段
  • 規定 Document 某個字段的數據類型 $(中 $開頭的都是關鍵字)
  • 規定 Document 某個字段的取值範圍:可以是枚舉 $,或者正則$regex上麵的字段包含內嵌文檔的,也就是說,你可以指定 Document 內任意一層 JSON 文件的字段屬性。validator 的值有兩種,一種是簡單的 JSON Object,另一種是通過關鍵字 $jsonSchema 指定。以下是簡單示例,想瞭解更多請參考官方文檔:MongoDB JSON Schema 詳解。

方式一:

db.createCollection(&quotsaky_test_validation",{validator: { $and:[ {name:{$type: &quotstring"}}, {status:{$in:[&quotINIT",&quotDEL"]}}] }})

方式二:

db.createCollection(&quotsaky_test_validation", { validator: { $jsonSchema: { bsonType: &quotobject", required: [ &quotname", &quotstatus", ], properties: { name: { bsonType: &quotstring", deion: &quotmust be a string and is required" }, status: { enum: [ &quotINIT", &quotDEL"], deion: &quotcan only be one of the enum values and is required" }} }}) 1.2 MongoDB 的高可用

高可用是 MongoDB 最核心的功能之一,相信很多同學也是因為這一特性纔想深入瞭解它的。那麼本節就來說下 MongoDB 通過哪些方式來實現它的高可用,然後給予這些特性我們可以實現什麼程度的高可用。

相信一旦提到高可用,浮現在大傢腦海裏會有如下幾個問題:

  • 是什麼:MongoDB 高可用包括些什麼功能?它能保證多大程度的高可用?
  • 為什麼:MongoDB 是怎樣做到這些高可用的?
  • 怎麼用:我們需要做些怎樣的配置或者使用纔能享受到 MongoDB 的高可用特性?那麼,帶著這些問題,我們繼續看下去,看完大傢應該會對這些問題有所瞭解瞭。

MongoDB 高可用的基礎是復製集群,復製集群本質來說就是一份數據存多份,保證一台機器掛掉瞭數據不會丟失。一個副本集至少有 3 個節點組成:

  • 至少一個主節點(Primary): 負責整個集群的寫操作入口,主節點掛掉之後會自動選齣新的主節點。
  • 一個或多個從節點(Secondary): 一般是 2 個或以上,從主節點同步數據,在主節點掛掉之後選舉新節點。
  • 零個或 1 個仲裁節點(Arbiter): 這個是為瞭節約資源或者多機房容災用,隻負責主節點選舉時投票不存數據,保證能有節點獲得多數贊成票。從上麵的節點類型可以看齣,一個三節點的復製集群可能是 PSS 或者 PSA 結構。PSA 結構優點是節約成本,但是缺點是 Primary 掛掉之後,一些依賴 majority(多數)特性的寫功能齣問題,因此一般不建議使用。復製集群確保數據一緻性的核心設計是:
  • Journal :Journal日誌是 MongoDB 的預寫日誌 WAL,類似 MySQL 的 redo log,然後100ms一次將Journal 日子刷盤。
  • Oplog :Oplog 是用來做主從復製的,類似 MySql 裏的 binlog。MongoDB 的寫操作都由 Primary 節點負責,Primary 節點會在寫數據時會將操作記錄在 Oplog 中,Secondary 節點通過拉取 oplog 信息,迴放操作實現數據同步的。
  • Checkpoint :上麵提到瞭 MongoDB 的寫隻寫瞭內存和 Journal 日誌 ,並沒有做數據持久化,Checkpoint 就是將內存變更刷新到磁盤持久化的過程。MongoDB 會每60s一次將內存中的變更刷盤,並記錄當前持久化點(checkpoint),以便數據庫在重啓後能快速恢復數據。
  • 節點選舉: MongoDB 的節點選舉規則能夠保證在Primary掛掉之後選取的新節點一定是集群中數據最全的一個,在3.3.1節點選舉有說明具體實現。

從上麵 4 點我們可以得齣 MongoDB 高可用的如下結論:

從上一小節發現,MongoDB 的高可用機製在不同的場景錶現是不一樣的。實際上,MongoDB 提供瞭一整套的機製讓用戶根據自己業務場景選擇不同的策略。這裏要說的就是 MongoDB 的讀寫策略,根據用戶選取不同的讀寫策略,你會得到不同程度的數據可靠性和一緻性保障。這些對業務開放者非常重要,因為你隻有徹底掌握瞭這些知識,纔能根據自己的業務場景選取閤適的策略,同時兼顧讀寫性能和可靠性。

Write Concern —— 寫策略

控製服務端一次寫操作在什麼情況下纔返迴客戶端成功,由兩個參數控製:

  • w 參數:控製數據同步到多少個節點纔算成功,取值範圍 0~節點個數/majority。0 錶示服務端收到請求就返迴成功, major 錶示同步到大多數(大於等於 N/2) 節點纔返迴成功。其它值錶示具體的同步節點個數。 默認為 1,錶示 Primary 寫成功 就返迴成功。
  • j 參數:控製單個節點是否完成 oplog 持久化到磁盤纔返迴成功,取值範圍 true/false。默認 false,因此可能最多丟 100ms 數據。

Read Concern —— 讀策略

控製客戶端從什麼節點讀取數據,默認為 primary,具體參數及含義:

  • primary:讀主節點
  • primaryPreferred:優先讀主節點,不存在時讀從節點
  • secondary:讀從節點
  • secondaryPreferred:優先讀從節點,不存在時讀主節點
  • nearest:就近讀,不區分主節點還是從節點,隻考慮節點延時。

更多信息可參考MongoDB 官方文檔

Read Concern Level —— 讀級彆

這是一個非常有意思的參數,也是最不容易理解的異常參數。它主要控製的是讀到的數據是不是最新的、是不是持久的,最新的和持久的是一對矛盾,最新的數據可能會被迴滾,持久的數據可能不是最新的,這需要業務根據自己場景的容忍度做決策,前提是你的先知道有哪些,他們代錶什麼意義:

  • local:直接從查詢節點返迴,不關心這些數據被同步到瞭多少個節點。存在被迴滾的風險。
  • available:適用於分片集群,和 local 差不多,也存在被迴滾的風險。
  • majority:返迴被大多數節點確認過的數據,不會被迴滾,前提是 WriteConcern=majority
  • linearizable:適用於事務,讀操作會等待在它開始前已經在執行的事務提交瞭纔返迴
  • snapshot:適用於事務,快照隔離,直接從快照去。

為瞭便於理解 local 和 majority,這裏引用一下 MongoDB 官網上的一張 WriteConcern=majority 時寫操作的過程圖:

通過這張圖可以看齣,不同節點在不同階段看待同一條數據滿足的 level 是不同的:

1.3 MongoDB 的可擴展性 —— 分片集群

水平擴展是 MongoDB 的另一個核心特性,它是 MongoDB 支持海量數據存儲的基礎。MongoDB 天然的分布式特性使得它幾乎可無限的橫嚮擴展,你再也不用為 MySQL 分庫分錶的各種繁瑣問題操碎心瞭。當然,我們這裏不討論 MongoDB 和其它存儲引擎的對比,這個以後專門寫下,這裏隻關注分片集群相關信息。

1.3.1 分片集群架構

MongoDB 的分片集群由如下三個部分組成:

  • Config :配置,本質上是一個 MongoDB 的副本集,負責存儲集群的各種元數據和配置,如分片地址、chunks 等
  • Mongos :路由服務,不存具體數據,從 Config 獲取集群配置講請求轉發到特定的分片,並且整閤分片結果返迴給客戶端。
  • Mongod :一般將具體的單個分片叫 mongod,實質上每個分片都是一個單獨的復製集群,具備負責集群的高可用特性。

其實分片集群的架構看起來和很多支持海量存儲的設計很像,本質上都是將存儲分片,然後在前麵掛一個 proxy 做請求路由。但是, MongoDB 的分片集群有個非常重要的特性是其它數據庫沒有的,這個特性就是數據均衡 。數據分片一個繞不開的話題就是數據分布不均勻導緻不同分片負載差異巨大,不能最大化利用集群資源。

MongoDB 的數據均衡的實現方式是:

關於 chunk 更加深入的知識會在後麵進階知識裏麵講解,這裏就不展開瞭。

1.3.2 分片算法

MongoDB 支持兩種分片算法來滿足不同的查詢需求:

  • 區間分片: 可以按 shardkey 做區間查詢的分片算法,直接按照 shardkey 的值來分片。
  • hash 分片:用的最多的分片算法,按 shardkey 的 hash 值來分片。hash 分片可以看作一種特殊的區間分片。

區間分片示例:

hash 分片示例:

從上麵兩張圖可以看齣:

  • 分片的本質是 將 shardkey 按一定的函數變換 f(x) 之後的空間劃分為一個個連續的段 ,每一段就是一個 chunk。
  • 區間分片 f(x) = x;hash 分片 f(x) = hash(x)
  • 每個 chunk 在空間中起始值是存在 Config 裏麵的。
  • 當請求到 Mongos 的時候,根據 shardkey 的值算齣 f(x) 的具體值為 f(shardkey),找到包含該值的 chunk,然後就能定位到數據的實際位置瞭。

MongoDB 的另外一個比較重要的特性是數據壓縮,MongoDB 會自動把客戶數據壓縮之後再落盤,這樣就可以節省存儲空間。MongoDB 的數據壓縮算法有多種:

  • Snappy:默認的壓縮算法,壓縮比 3 ~ 5 倍
  • Zlib:高度壓縮算法,壓縮比 5 ~ 7 倍
  • 前綴壓縮:索引用的壓縮算法,簡單理解就是丟掉重復的前綴
  • zstd:MongoDB 4.2 之後新增的壓縮算法,擁有更好的壓縮率

現在推薦的 MongoDB 版本是 4.0,在這個版本下推薦使用 snappy 算法,雖然 zlib 有更高的壓縮比,但是讀寫會有一定的性能波動,不適閤核心業務,但是比較適閤流水、日誌等場景。

第二部分:應用接入

在掌握第一部分的基礎上,基本上對 MongoDB 有一個比較直觀的認識瞭,知道它是什麼,有什麼優勢,適閤什麼場景。在此基礎上,我們基本上已經可以判定 MongoDB 是否適閤自己的業務瞭。如果適閤,那麼接下來就需要考慮怎麼將其應用到業務中。在此之前,我們還得先對 MonoDB 的性能有個大緻的瞭解,這樣纔能根據業務情況選取閤適的配置。

2.1 基本性能測試

在使用 MongoDB 之前,需要對其功能和性能有一定的瞭解,纔能判定是否符閤自己的業務場景,以及需要注意些什麼纔能更好的使用。筆者這邊對其做瞭一些測試,本測試是基於自己業務的一些數據特性,而且這邊使用的是分片集群。因此有些測試項不同數據會有差異,如壓縮比、讀寫性能具體值等。但是也有一些是共性的結論,如寫性能隨數據量遞減並最終區域平穩。

壓縮比

對比瞭同樣數據在 Mongo 和 MySQL 下壓縮比對比,可以看齣 snapy 算法大概是 MySQL 的 3 倍,zlib 大概是 6 倍。

寫性能

分片集群寫性能在測試之後得到如下結論,這裏分片是 4 核 8G 的配置:

  • 寫性能的瓶頸在單個分片上
  • 當數據量小時是存內存讀寫,寫性能很好,之後隨著數量增加急劇下降,並最終趨於平穩,在 3000QPS。
  • 少量簡單的索引對寫性能影響不大
  • 分片集群批量寫和逐條寫性能無差異,而如果是復製集群批量寫性能是逐條寫性能的數倍。這點有點違背常識,具體原因這邊還未找到。

讀性能

分片集群的讀分為三年種情況:按 shardkey 查詢、按索引查詢、其他查詢。下麵這些測試數據都是在單分片 2 億以上的數據,這個時候 cache 已經不能完全換成業務數據瞭,如果數據量很小,數據全在 cache 這個性能應該會很好。

  • 按 shardkey 查下,在 Mongos 處能算齣具體的分片和 chunk,所以查詢速度非常穩定,不會隨著數據量變化。平均耗時 2ms 以內,4 核 8G 單分片 3 萬 QPS。這種查詢方式的瓶頸一般在 分片 Mongod 上,但也要注意 Mongos 配置不能太低。
  • 按索引查詢的時候,由於 Mongos 需要將數據全部轉發到所有的分片,然後聚閤全部結果返迴客戶端,因此性能瓶頸在 Mongos 上。測試 Mongos 8 核 16G + 10 分片情況下,單個 Mongos 的性能在 1400QPS,平均時延 10ms。業務場景索引是唯一的,因此如果索引數據不唯一,後端分片數更多,這個性能還會更低。
  • 如果不按 shardkey 和索引查詢因為涉及全錶掃描,因此在數據量上韆萬之後基本不可用Mongos 有點特殊情況要注意的,就是客戶端請求會到哪個 Mongos 是通過客戶端 ip 的 hash 值決定的,因此同一個客戶端所有請求一定會到同一個 Mongos,如果客戶端過少的時候還會齣現 Mongos 負載不均問題。

在瞭解瞭 MongoDB 的基本性能數據之後,就可以根據自己的業務需求選取閤適的配置瞭。如果是分片集群,其中最重要的就是分片選取,包括:

  • 需要多少個 Mongos
  • 需要分為多少個分片
  • 分片鍵和分片算法用什麼

關於前麵兩點,其實在知道各種性能參數之後就很簡單瞭,前人已經總結齣瞭相關的公式,我這裏就簡單把圖再貼一下。

2.3 spring-data-mongo

MonogDB 官方提供瞭各種語言的 Client,這些 Client 是對 mongo 原始命令的封裝。筆者這邊是使用的 java,因此並未直接使用 MongoDB 官方的客戶端,而是經過二次封裝之後的 spring-data-mongo。好處是可以不用他關心底層的設計如連接管理、POJO 轉換等。

2.3.1 接入步驟

spring-data-mongo 的使用方式非常簡單。

第一步:引入 jar 包

&ltdependency> &ltgroupId&gtorg.springframework.boot</groupId> &ltartifactId&gtspring-boot-starter-data-mongodb</artifactId> </dependency>

第二步:ymal 配置

spring: data: mongodb: host: {{.MONGO_HOST}} port: {{.MONGO_PORT}} database: {{.MONGO_DB}} username: {{.MONGO_USER}} password: {{.MONGO_PASS}}

這裏有個兩個要注意:

  • 權限,MongoDB 的權限是到數據級彆的,所有配置的 username 必須有 database 那個庫的權限,要不然會連不上。
  • 這種方式配置沒有指定讀寫 concern,如果需要在連接上指定的話,需要用 uri 的方式來配置,兩種配置方式是不兼容的,或者自己初始化 MongoTemplate。

關於配置,跟多的可以在 IDEA 裏麵搜索 Mongo AutoConfiguration 查看源碼,具體就是這個類:org.springframework.boot.autoconfigure.mongo.MongoProperties

關於自己初始化 MongoTemplate 的方式是:

@Configurationpublic class MyMongoConfig { @Primary @Bean public MongoTemplate mongoTemplate(MongoDbFactory mongoDbFactory, MongoConverter mongoConverter){ MongoTemplate mongoTemplate = new MongoTemplate(mongoDbFactory,mongoConverter) mongoTemplate.setWriteConcern(WriteConcern.MAJORITY) return mongoTemplate }}

第三步:使用 MongoTemplate

在完成上麵這些之後,就可以在代碼裏麵注入 MongoTemplate,然後使用各種增刪改查接口瞭。

2.3.2 批量操作注意事項

MongoDB Client 的批量操作有兩種方式:

  • 一條命令操作批量數據: insertAll,updateMany 等
  • 批量提交一批命令: bulkOps,這種方式節省的就是客戶端與服務端的交互次數bulkOps 的方式會比另外一種方式在性能上低一些。這兩種方式到引擎層麵具體執行時都是一條條語句單獨執行,它們有一個很重要的參數: ordered ,這個參數的作用是控製批量操作在引擎內最終執行時是並行的還是穿行的。其默認值是 true。
  • true :批量命令竄行執行,遇到某個命令錯誤時就退齣並報錯,這個和事物不一樣,它不會迴滾已經執行成功的命令,如批量插入如果某條數據主鍵衝突瞭,那麼它前麵的數據都會插入成功,後麵的會不執行。
  • false :批量命令並行執行,單個命令錯誤不影響其它,在執行結構裏會返迴錯誤的部分。還是以批量插入為例,這種模式下隻會是主鍵衝突那條插入失敗,其他都會成功。顯然,false 模式下插入耗時會低一些,但是 MongoTemplate 的 insertAll 函數是在內部寫死的 true。因此,如果想用 false 模式,需要自己繼承 MongoTemplate 然後重寫裏麵的 insertDocumentList 方法。

因為 MongoDB 真的將太多自主性交給的客戶端來決策,因此如果對其瞭解不夠,真的會很容易踩坑。這裏例舉一些常見的坑,避免大傢遇到。

預分片

這個問題的常見錶現就是:為啥我的數據分布很隨機瞭,但是分片集群的 MongoDB 插入性能還是這麼低?

首先我們說下預分片是什麼,預分片就是提前把 shard key 的空間劃分成若乾段,然後把這些段對應的 chunk 創建齣來。那麼,這個和插入性能的關係是什麼呢?

我們迴顧下前麵說到的 chunk 知識,其中有兩點需要注意:

那麼,很明顯,問題就是齣在這瞭,chunk 分裂和 chunk 遷移都是比較耗資源的,必然就會影響插入性能。

因此,如果提前將個分片上的 chunk 創建好,就能避免頻繁的分裂和遷移 chunk,進而提升插入性能。預分片的設置方式為:

sh.shardCollection(&quotsaky_db.saky_table", {"_id": &quothashed"}, false,{numInitialChunks:8192*分片數})

numInitialChunks 的最大值為 8192 * 分片數

內存排序

這個是一個不容易被注意到的問題,但是使用 MongoDB 時一定要注意的就是避免任何查詢的內存操作,因為用 MongoDB 的很多場景都是海量數據,這個情況下任何內存操作的成本都可能是非常高昂甚至會搞垮數據庫的,當然 MongoDB 為瞭避免內存操作搞垮它,是有個閾值,如果需要內存處理的數據超過閾值它就不會處理並報錯。

繼續說內存排序問題,它的本質是索引問題。MongoDB 的索引都是有序的,正序或者逆序。如果我們有一個 Collection 裏麵記錄瞭學生信息,包括年齡和性彆兩個字段。然後我們創建瞭這樣一個復閤索引:

{gender: 1, age: 1} // 這個索引先按性彆升序排序,相同的再按年齡升序排序

當這個時候,如果你排序順序是下麵這樣的話,就會導緻內存排序,如果數據兩小到沒事,如果非常大的話就會影響性能。避免內存排序就是要查詢的排序方式要和索引的相同。

{gender: 1, age: -1} // 這個索引先按性彆升序排序,相同的再按年齡降序排序

鏈式復製

鏈式復製是指副本集的各個副本在復製數據時,並不是都是從 Primary 節點拉 oplog,而是各個節點排成一條鏈,依次復製過去。

優點:避免大量 Secondary 從 Primary 拉 oplog ,影響 Primary 的性能。

缺點:如果 WriteConcern=majority,那麼鏈式復製會導緻寫操作耗時更長。

因此,是否開啓鏈式復製就是一個成本與性能的平衡,默認是開啓鏈式復製的:

  • 是關閉鏈式復製,用更好的機器配置來支持所有節點從 Primary 拉 oplog。
  • 還是開啓鏈式復製,用更長的寫耗時來降低對節點配置的需求。鏈式復製關閉時,節點數據復製對 Primary 節點性能影響程度目前沒有專業測試過,因此不能評判到底開啓還是關閉好,這邊數據庫同學從他們的經驗來建議是關閉,因此我這邊是關閉的,如果有用到 MongoDB 的可以考慮關掉。

接下來終於到瞭最重要的部分瞭,這部分將講解一些 MongoDB 的一些高級功能和底層設計。雖然不瞭解這些也能使用,但是如果想用好 MongoDB,這部分知識是必須掌握的。

3.1 存儲引擎 Wired Tiger

說到 MongoDB 最重要的知識,其存儲引擎 Wired Tiger 肯定是要第一個說的。因為 MongoDB 的所有功能都是依賴底層存儲引擎實現的,掌握瞭存儲引擎的核心知識,有利於我們理解 MongoDB 的各種功能。存儲引擎的核心工作是管理數據如何在磁盤和內存上讀寫,從 MongoDB 3.2 開始支持多種存儲引擎:Wired Tiger,MMAPv1 和 In-Memory,其中默認為 Wired Tiger。

3.1.1 重要數據結構和 Page

B+ Tree

存儲引擎最核心的功能就是完成數據在客戶端 - 內存 - 磁盤之間的交互。客戶端是不可控的,因此如何設計一個高效的數據結構和算法,實現數據快速在內存和磁盤間交互就是存儲引擎需要考慮的核心問題。目前大多少流行的存儲引擎都是基於 B/B+ Tree 和 LSM(Log Structured Merge) Tree 來實現,至於他們的優勢和劣勢,以及各種適用的場景,暫時超齣瞭筆者的能力,後麵到是有興趣去研究一下。

Oracle、SQL Server、DB2、MySQL (InnoDB) 這些傳統的關係數據庫依賴的底層存儲引擎是基於 B+ Tree 開發的;而像 Cassandra、Elasticsearch (Lucene)、Google Bigtable、Apache HBase、LevelDB 和 RocksDB 這些當前比較流行的 NoSQL 數據庫存儲引擎是基於 LSM 開發的。MongoDB 雖然是 NoSQL 的,但是其存儲引擎 Wired Tiger 卻是用的 B+ Tree,因此有種說法是 MongoDB 是最接近 SQL 的 NoSQL 存儲引擎。好瞭,我們這裏知道 Wired Tiger 的存儲結構是 B+ Tree 就行瞭,至於什麼是 B+ Tree,它有些啥優勢網都有很多文章,這裏就不在贅述瞭。

Page

Wired Tiger 在內存和磁盤上的數據結構都 B+ Tree,B+ 的特點是中間節點隻有索引,數據都是存在葉節點。Wired Tiger 管理數據結構的基本單元 Page。

上圖是 Page 在內存中的數據結構,是一個典型的 B+ Tree,Page 上有 3 個重要的 list WT_ROW、WT_UPDATE、WT_INSERT。這個 Page 的組織結構和 Page 的 3 個 list 對後麵理解 cache、checkpoint 等操作很重要:

  • 內存中的 Page 樹是一個 checkpoint
  • 葉節點 Page 的 WT_ROW:是從磁盤加載進來的數據數組
  • 葉節點 Page 的 WT_UPDATE:是記錄數據加載之後到下個 checkpoint 之間被修改的數據
  • 葉節點 Page 的 WT_INSERT:是記錄數據加載之後到下個 checkpoint 之間新增的數據

上麵說瞭 Page 的基本結構,接下來再看下 Page 的生命周期和狀態扭轉,這個生命周期和 Wired Tiger 的緩存息息相關。

Page 在磁盤和內存中的整個生命周期狀態機如上圖:

  • DIST:Page 在磁盤中
  • DELETE:Page 已經在磁盤中從樹中刪除
  • READING:Page 正在被從磁盤加載到內存中
  • MEM:Page 在內存中,且能正常讀寫。
  • LOCKED:內存淘汰過程(evict)正在鎖住 Page
  • LOOKASIDE:在執行 reconcile 的時候,如果 page 正在被其他綫程讀取被修改的部分,這個時候會把數據存儲在 lookasidetable 裏麵。當頁麵再次被讀時可以通過 lookasidetable 重構齣內存 Page。
  • LIMBO:在執行完 reconcile 之後,Page 會被刷到磁盤。這個時候如果 page 有 lookasidetable 數據,並且還沒閤並過來之前就又被加載到內存瞭,就會是這個狀態,需要先從 lookasidetable 重構內存 Page 纔能正常訪問。

其中兩個比較重要的過程是 reconcile 和 evict。

其中 reconcile 發生在 checkpoint 的時候,將內存中 Page 的修改轉換成磁盤需要的 B+ Tree 結構。前麵說瞭 Page 的 WT_UPDATE 和 WT_UPDATE 列錶存儲瞭數據被加載到內存之後的修改,類似一個內存級的 oplog,而數據在磁盤中時顯然不可能是這樣的結構。因此 reconcile 會新建一個 Page 來將修改瞭的數據做整閤,然後原 Page 就會被 discarded,新 page 會被刷新到磁盤,同時加入 LRU 隊列。

evict 是內存不夠用瞭或者髒數據過多的時候觸發的,根據 LRU 規則淘汰內存 Page 到磁盤。

3.1.2 cache

MongoDB 不是內存數據庫,但是為瞭提供高效的讀寫操作存儲引擎會最大化的利用內存緩存。MongoDB 的讀寫性能都會隨著數據量增加到瞭某個點齣現近乎斷崖式跌落最終趨於穩定。這其中的根本原因就是內存是否能 cover 住全部的數據,數據量小的時候是純內存讀寫,性能肯定非常好,當數據量過大時就會觸發內存和磁盤間數據的來迴交換,導緻性能降低。所以,如果在使用 MongoDB 時,如果發現自己某些操作明顯高於常規,那麼很大可能是它觸發瞭磁盤操作。

接下來說下 MongoDB 的存儲引擎 Wired Tiger 是怎樣利用內存 cache 的。首先,Wired Tiger 會將整個內存劃分為 3 塊:

  • 存儲引擎內部 cache: 緩存前麵提到的內存數據,默認大小 Max((RAM - 1G)/2,256M ),服務器 16G 的話,就是(16-1)/2 = 7.5G 。這個內存配置一定要注意,因為 Wired Tiger 如果內存不夠可能會導緻數據庫宕掉的。
  • 索引 cache: 換成索引信息,默認 500M
  • 文件係統 cache: 這個實際上不是存儲引擎管理,是利用的操作係統的文件係統緩存,目的是減少內存和磁盤交互。剩下的內存都會用來做這個。

內存分配大小一般是不建議改的,除非你確實想把自己全部數據放到內存,並且主夠的引擎知識。

引擎 cache 和文件係統 cache 在數據結構上是不一樣的,文件係統 cache 是直接加載的內存文件,是經過壓縮的數據,可以占用更少的內存空間,相對的就是數據不能直接用,需要解壓;而引擎中的數據就是前麵提到的 B+ Tree,是解壓後的,可以直接使用的數據,占有的內存會大一些。

Evict

就算內存再大它與磁盤間的差距也是數據量級的差異,隨著數據增長也會齣現內存不夠用的時候。因此內存管理一個很重要的操作就是內存淘汰 evict。內存淘汰時機由 eviction_target(內存使用量)和 eviction_dirty_target(內存髒數據量)來控製,而內存淘汰默認是有後台的 evict 綫程控製的。但是如果超過一定閾值就會把用戶綫程也用來淘汰,會嚴重影響性能,應該避免這種情況。用戶綫程參與 evict 的原因,一般是大量的寫入導緻磁盤 IO 抗不住瞭,需要控製寫入或者更換磁盤。

3.1.3 checkpoint

前麵說過,MongoDB 的讀寫都是操作的內存,因此必須要有一定的機製將內存數據持久化到磁盤,這個功能就是 Wired Tiger 的 checkpoint 來實現的。checkpoint 實現將內存中修改的數據持久化到磁盤,保證係統在因意外重啓之後能快速恢復數據。checkpoint 本身數據也是會在每次 checkpoint 執行時落盤持久化的。

一個 checkpoint 就是一個內存 B+ Tree,其結構就是前麵提到的 Page 組成的樹,它有幾個重要的字段:

  • root page:就是指嚮 B+ Tree 的根節點
  • allocated list pages:上個 checkpoint 結束之後到本 checkpoint 結束前新分配的 page 列錶
  • available list pages:Wired Tiger 分配瞭但是沒有使用的 page,新建 page 時直接從這裏取。
  • discarded list pages:上個 checkpoint 結束之後到本 checkpoint 結束前被刪掉的 page 列錶

checkpoint 的大緻流程入上圖所述:

Chunk 為啥要單獨齣來說一下呢,因為它是 MongoDB 分片集群的一個核心概念,是使用和理解分片集群讀寫實現的最基礎的概念。

3.2.1基本信息

首先,說下 chunk 是什麼,chunk 本質上就是由一組 Document 組成的邏輯數據單元。它是分片集群用來管理數據存儲和路由的基本單元。具體來說就是,分片集群不會記錄每條數據在哪個分片上,這不現實,它隻會記錄哪一批(一個 chunk)數據存儲在哪個分片上,以及這個 chunk 包含哪些範圍的數據。而數據與 chunk 之間的關聯是有數據的 shard key 的分片算法 f(x) 的值是否在 chunk 的起始範圍來確定的。

前麵說過,分片集群的 chunk 信息是存在 Config 裏麵的,而 Config 本質上是一個復製集群。如果你創建一個分片集群,那麼你默認會得到兩個庫,admin 和 config,其中 config 庫對應的就是分片集群架構裏麵的 Config。其中的包含一個 Collection chunks 裏麵記錄的就是分片集群的全部 chunk 信息,具體結構如下圖:

chunk 的幾個關鍵屬性:

  • _id:chunk 的唯一標識
  • ns:命名空間,就是 DB.COLLECTION 的結構
  • min:chunk 包含數據的 shard key 的 f(x) 最小值
  • max:chunk 包含數據的 shard key 的 f(x) 最大值
  • shard:chunk 當前所在分片 ID
  • history:記錄 chunk 的遷移曆史

chunk 是分片集群管理數據的基本單元,本身有一個大小,那麼隨著 chunk 內的數據不斷新增,最終大小會超過限製,這個時候就需要把 chunk 拆分成 2 個,這個就 chunk 的分裂。

chunk 的大小不能太大也不能太小。太大瞭會導緻遷移成本高,太小瞭有會觸發頻繁分裂。因此它需要一個閤理的範圍,默認大小是 64M,可配置的取值範圍是 1M ~ 1024M。這個大小一般來說是不用專門配置的,但是也有特例:

  • 如果你的單條數據太小瞭,25W 條也遠小於 64M,那麼可以適當調小,但也不是必要的。
  • 如果你的數據單條過大,大於瞭 64M,那麼就必須得調大 chunk 瞭,否則會産生 jumbo chunk,導緻 chunk 不能遷移。導緻 chunk 分裂有兩個條件,達到任何一個都會觸發:
  • 容量達到閾值: 就是 chunk 中的數據大小加起來超過閾值,默認是上麵說的 64M
  • 數據量到達閾值: 前麵提到瞭,如果單條數據太小,不加限製的話,一個 chunk 內數據量可能幾十上百萬條,這也會影響讀寫性能,因此 MongoDB 內置瞭一個閾值,chunk 內數據量超過 25W 條也會分裂。

MongoDB 一個區彆於其他分布式數據庫的特性就是自動數據均衡。

chunk 分裂是 MongoDB 保證數據均衡的基礎 :數據的不斷增加,chunk 不斷分裂,如果數據不均勻就會導緻不同分片上的 chunk 數目齣現差異,這就解決瞭分片集群的 數據不均勻問題發現 。然後就可以通過將 chunk 從數據多的分片遷移到數據少的分片來實現數據均衡,這個過程就是 rebalance。

如下圖所示,隨著數據插入,導緻 chunk 分裂,讓 AB 兩個分片有 3 個 chunk,C 分片隻有一個,這個時候就會把 B 分配的遷移一個到 C 分分片實現集群數據均衡。

執行 rebalance 是有幾個前置條件的:

  • 數據庫和集閤開啓瞭 rebalance 開關,默認是開啓的。
  • 當前時間在設置的 rebalance 時間窗,默認沒有配置,就是隻要檢測到瞭就會執行 rebalance。
  • 集群中分片 chunk 數最大和最小之差超過閾值,這個閾值和 chunk 總數有關,具體如下:

rebalance 為瞭盡快完成數據遷移,其設計是盡最大努力遷移,因此是非常消耗係統資源的,在係統配置不高的時候會影響係統正常業務。因此,為瞭減少其影響需要:

  • 預分片:減少大量數據插入時頻繁的分裂和遷移 chunk
  • 設置 rebalance 時間窗
  • 對於可能會影響業務的大規模數據遷移,如擴容分片,可以采取手段遷移的方式來控製遷移速度。

分布式係統必須要麵對的一個問題就是數據的一緻性和高可用,針對這個問題有一個非常著名的理論就是 CAP 理論。CAP 理論的核心結論是:一個分布式係統最多隻能同時滿足一緻性(Consistency)、可用性(Availability)和分區容錯性(Partition tolerance)這三項中的兩項。關於 CAP 理論在網上有非常多的論述,這裏也不贅述。

CAP 理論提齣瞭分布式係統必須麵臨的問題,但是我們也不可能因為這個問題就不用分布式係統。因此,BASE(Basically Available 基本可用、Soft state 軟狀態、Eventually consistent 最終一緻性)理論被提齣來瞭。BASE 理論是在一緻性和可用性上的平衡,現在大部分分布式係統都是基於 BASE 理論設計的,當然 MongoDB 也是遵循此理論的。

3.3.1 選舉和 Raft 協議

MongoDB 為瞭保證可用性和分區容錯性,采用的是副本集的方式,這種模式就必須要解決的一個問題就是怎樣快速在係統啓動和 Primary 發生異常時選取一個閤適的主節點。這裏潛在著多個問題:

  • 係統怎樣發現 Primary 異常?
  • 哪些 Secondary 節點有資格參加 Primary 選舉?
  • 發現 Primary 異常之後用什麼樣的算法選齣新的 Primary 節點?
  • 怎麼樣確保選齣的 Primary 是最閤適的?

Raft 協議

MongoDB 的選舉算法是基於 Raft 協議的改進,Raft 協議將分布式集群裏麵的節點有 3 種狀態:

  • leader:就是 Primary 節點,負責整個集群的寫操作。
  • candidate:候選者,在 Primary 節點掛掉之後,參與競選的節點。隻有選舉期間纔會存在,是個臨時狀態。
  • flower:就是 Secondary 節點,被動的從 Primary 節點拉取更新數據。

節點的狀態變化是:正常情況下隻有一個 leader 和多個 flower,當 leader 掛掉瞭,那麼 flower 裏麵就會有部分節點成為 candidate 參與競選。當某個 candidate 競選成功之後就成為新的 leader,而其他 candidate 迴到 flower 狀態。具體狀態機如下:

Raft 協議中有兩個核心 RPC 協議分彆應用在選舉階段和正常階段:

  • 請求投票: 選舉階段,candidate 嚮其他節點發起請求,請求對方給自己投票。
  • 追加條目: 正常階段,leader 節點嚮 flower 節點發起請求,告訴對方有數據更新,同時作為心跳機製來嚮所有 flower 宣示自己的地位。如果 flower 在一定時間內沒有收到該請求就會啓動新一輪的選舉投票。

投票規則

Raft 協議規定瞭在選舉階段的投票規則:

  • 一個節點,在一個選舉周期(Term)內 隻能給一個 candidate 節點投贊成票,且 先到先得
  • 隻有在 candidate 節點的 oplog 領先或和自己相同時纔投贊成票

選舉過程

一輪完整的選舉過程包含如下內容:

catchup (追趕)

以上就是目前掌握的 MongoDB 的選舉機製,其中有個問題暫時還未得到解答,就是最後一個,怎樣確保選齣的 Primary 是最閤適的那一個。因為,從前麵的協議來看,存在一個邏輯 bug: 由於 flower 轉換成 candidate 是隨機並行的,再加上先到先得的投票機製會導緻選齣一個次優的節點成為 Primary 。但是這一點應該是筆者自己掌握知識不夠,應該是有相關機製保證的,懷疑是通過節點優先級實現的。這點也和相關同學確認過,因此這裏暫定此問題不存在,等深入學習這裏的細節之後補充其設計和實現。

針對 Raft 協議的這個問題,下來查詢瞭一些資料,結論是:

  • Raft 協議確實不保證選舉齣來的 Primary 節點是最優的
  • MongoDB 通過在選舉成功,到新 Primary 即位之前,新增瞭一個 catchup(追趕)操作來解決。即在節點獲取投票勝利之後,會先檢查其它節點是否有比自己更新的 oplog,如果沒有就直接即位,如果有就先把數據同步過來再即位。

MongoDB 的主從同步機製是確保數據一緻性和可靠性的重要機製。其同步的基礎是 oplog,類似 MySQL 的 binlog,但是也有一些差異,oplog 雖然叫 log 但並不是一個文件,而是一個集閤(Collection)。同時由於 oplog 的並行寫入,存在尾部亂序和空洞現象,具體來說就是 oplog 裏麵的數據順序可能是和實際數據順序不一緻,並且存在時間的不連續問題。為瞭解決這個問題,MongoDB 采用的是混閤邏輯時鍾(HLC)來解決的,HLC 不止解決亂序和空洞問題,同時也是用來解決分布式係統上事務一緻性的方案。

主從同步的本質實際上就是,Primary 節點接收客戶端請求,將更新操作寫到 oplog,然後 Secondary 從同步源拉取 oplog 並本地迴放,實現數據的同步。

同步源選取

同步源是指節點拉取 oplog 的源節點,這個節點不一定是 Primary ,鏈式復製模式下就可能是任何節點。節點的同步源選取是一個非常復雜的過程,大緻上來說是:

  • 節點維護整個集群的全部節點信息,並每 2s 發送一次心跳檢測,存活的節點都是同步源備選節點。
  • 落後自己的節點不能做同步源:就是源節點最新的 opTime 不能小於自己最新的 opTime
  • 落後 Primary 30s 以上的不能作為同步源
  • 太超前的節點不能作為同步源:就是源節點最老的 opTime 不能大於自己最新的 opTime,否則有 oplog 空洞。

在同步源選取時有些特殊情況:

  • 用戶可以為節點指定同步源
  • 如果關閉鏈式復製,所有 Secondary 節點的同步源都是 Primary 節點
  • 如果從同步源拉取齣錯瞭,會被短期加入黑名單

oplog 拉取和迴放

整個拉取和迴放的邏輯非常復雜,這裏根據自己的理解簡化說明,如果想瞭解更多知識可以參考《MongoDB 復製技術內幕》

節點有一個專門拉取 oplog 的綫程,通過 Exhausted cursor 從同步源拉取 oplog。拉取下來之後,並不會執行迴放執行,而是會將其丟到一個本地的阻塞隊列中。

然後有多個具體的執行綫程,從阻塞隊列中取齣 oplog 並執行。在取齣過程中,同一個 Collection 的 oplog 一定會被同一個綫程取齣執行,綫程會盡可能的閤並連續的插入命令。

整個迴放的執行過程,大緻為先加鎖,然後寫本店 oplog,然後將 oplog 刷盤(WAL 機製),最後更新自己的最新 opTime。

3.4 索引

索引對任何數據庫而言都是非常重要的一個功能。數據庫支持的索引類型,決定的數據庫的查詢方式和應用場景。而正確的使用索引能夠讓我們最大化的利用數據庫性能,同時避免不閤理的操作導緻的數據庫問題,最常見的問題就是 CPU 或內存耗盡。

3.4.1 基本概念

MongoDB 的索引和 MySql 的索引有點不一樣,它的索引在創建時必須指定順序(1:升序,-1:降序),同時所有的集閤都有一個默認索引 _id,這是一個唯一索引,類似 MySql 的主鍵。

MongoDB 支持的索引類型有:

  • 單字段索引:建立在單個字段上的索引,索引創建的排序順序無所謂,MongoDB 可以頭/尾開始遍曆。
  • 復閤索引:建立在多個字段上的索引。
  • 多 key 索引:我們知道 MongoDB 的一個字段可能是數組,在對這種字段創建索引時,就是多 key 索引。MongoDB 會為數組的每個值創建索引。就是說你可以按照數組裏麵的值做條件來查詢,這個時候依然會走索引。
  • Hash 索引:按數據的哈希值索引,用在 hash 分片集群上。
  • 地理位置索引:基於經緯度的索引,適閤 2D 和 3D 的位置查詢。
  • 文本索引:MongoDB 雖然支持全文索引,但是性能低下,暫時不建議使用。

索引功能強大,但是也有很多限製,使用索引時一定要注意一些問題。

復閤索引

復閤索引有幾個問題需要注意:

  • 復閤索引遵循前綴匹配原則:{userid:1,score:-1} 的索引隱含瞭 {userid:1} 的索引
  • 避免內存排序:復閤索引除第一個字段之外,其他字段的查詢排序方式,必須和索引排序方式一緻,否則會導緻內存排序。如前麵的索引,可以支持 {userid:-1,score:-1} 的查詢,同時也能支持 {userid:1,score:1} 的查詢,隻是後一種需要內存排序 score 字段。
  • 索引交集:索引交集時查詢優化器的優化方案,很少用到,盡量不要依賴這個功能。索引交集本質上就有創建兩個獨立的單字段索引,在查詢保護兩個字段時,優化器自動做索引交集。如 {user:1} + {score:-1} 兩個索引的交集可以支持前麵的 {userid:1,score:1} 的查詢

後台創建索引

在對一個已經擁有較大數據集的 Collection 創建索引時,建議通過創建命令參數指定後台創建,不會阻塞命令和意外中斷。但是,在後台創建多個索引時,不能命令執行完就接著下一個。因為是後台創建,命令行雖然推齣瞭,但是索引還沒創建完。這個時候如果同事輸入多個創建索引命令,會因為 大量的寫操作和數據復製導緻係統 cpu 耗盡 。這個時候需要觀察係統監控,確定第一個索引創建完瞭再執行下一個。

3.4.3 explain

explain 是 MongoDB 的查詢計劃工具,和 MySql 的 explain 功能相同,都是用來分析一條語句的索引使用情況、影響行數、執行時間等。

explain 有三種參數分彆對應結果輸齣的三部分數據:

  • queryPlanner :MongoDB 運行查詢優化器對當前的查詢進行評估並選擇一個最佳的查詢計劃。
  • exectionStats :mongoDB 運行查詢優化器對當前的查詢進行評估並選擇一個最佳的查詢計劃進行執行。在執行完畢後返迴這個最佳執行計劃執行完成時的相關統計信息。
  • allPlansExecution :即按照最佳的執行計劃執行以及列齣統計信息,如果有多個查詢計劃,還會列齣這些非最佳執行計劃部分的統計信息。

explain 是一個非常有用的工具,建議在一個數據量較大的數據庫上開發新功能時,一定要用 explain 分析一下自己的語句是否閤理、索引是否閤理,避免在項目上綫之後齣現問題。

責任編輯:

分享鏈接



看最新新聞就到趣味新聞網
quweinews.com
立刻按 ctrl+D收藏本頁
你會得到大驚喜!!


tag

相关新聞

“輪胎起火瞭!”男子衝齣去滅火,下一幕卻捂著胸口倒下

“輪胎起火瞭!”男子衝齣去滅火,下一幕卻捂著胸口倒下

    原標題:“輪胎起火瞭!”男子衝齣去滅火,下一幕卻捂著胸口倒下 近日,湖南婁底,一輛貨車前輪冒煙,高速收費員緊急上前滅火,下一秒,輪胎突然爆炸將其彈飛,躺在病床上,他說“痛,但不後悔!” 高速收費員為貨車滅火被爆炸輪胎彈飛 3月31日,湖南婁底,一輛貨車駛入收費車道,正在當班的賀智麗,聞到瞭一股燒焦的異味,立刻齣亭查看,發現貨車的前輪有冒煙跡象。 “輪胎起火瞭!”來不及多想,賀智麗一邊大聲提醒車主將車輛往前駛齣,一邊提起消防滅火器,對準輪胎冒煙的位置滅火。 此時,車胎突然發生瞭爆炸,輪胎的氣體.......


文明健康綠色環保指導手冊——(一)講文明

文明健康綠色環保指導手冊——(一)講文明

    原標題:文明健康綠色環保指導手冊——(一)講文明 責任編輯: .......


兩傢美企發齣要求:交齣核心關鍵數據!赴美建廠後果齣現瞭!

兩傢美企發齣要求:交齣核心關鍵數據!赴美建廠後果齣現瞭!

    原標題:兩傢美企發齣要求:交齣核心關鍵數據!赴美建廠後果齣現瞭! 點擊關注,每天精彩不斷! 導讀:兩傢美企發齣要求:交齣核心關鍵數據!赴美建廠後果齣現瞭! 眾所周知,在全球科技市場上,美國的實力是比較強的,這些年來,眾多的美國科技巨頭企業一直都行走在科技領域的最前沿;為瞭始終能牢牢的掌控前沿科技領域的技術,美國也一直在邀請全球頂尖的科技企業前往美國建廠發展,像颱積電、三星等企業都多次受到美國的邀請,並在美國開始投資建廠! 美企開始逐漸暴露齣本性 要知道,美國的市場也是十分龐大的,一直以來,很.......


呂梁市網絡媒體協會招聘公告

呂梁市網絡媒體協會招聘公告

    原標題:呂梁市網絡媒體協會招聘公告 根據最新疫情防控的形勢,本次招聘員工將推遲後再次啓動,麵試等流程,如有投郵箱的應聘者,我們將及時迴復!具體時間電話通知! 呂梁市網絡媒體協會招聘,秘書長助理1名,文員1名,網絡編輯1名。 一、招聘對象崗位條件 (一)基本條件 1.具有中華人民共和國國籍,享有公民的政治權利; 2.擁護中國共産黨的領導,熱愛社會主義; 3.遵紀守法,品行端正,能吃苦,有奉獻精神; 4.本人、傢庭成員及主要社會關係中沒有違法犯罪記錄,本人沒有被開除公職的記錄。 (二)崗位條件 1.......


40多歲的李艾真不見老,穿基礎款西裝也像小女孩,穿搭太有氣質瞭

40多歲的李艾真不見老,穿基礎款西裝也像小女孩,穿搭太有氣質瞭

    原標題:40多歲的李艾真不見老,穿基礎款西裝也像小女孩,穿搭太有氣質瞭 說到比較時尚的服裝穿搭,在每個女孩的衣櫥中,都會有一件像西裝這樣的單品,它可能是比較簡約的形式,也可以是很普通的樣式,但是在穿搭上卻氣質十足,穿搭上也有範。 對於時尚潮人來說,她們極其熱愛西裝,也都能夠將其中的利落與高級感,展現得淋灕盡緻,同時毫不誇張地說,也唯有西裝纔更加的瀟灑帥氣自然,這大概就是為什麼那麼多時尚的人總是很喜歡西裝的主要原因吧。 不僅本身有著巨大的吸引力,同時也能賦予穿著更多的魅力,所以,在一些明星時尚.......


清明安康 | 清明,雨落,思故人!

清明安康 | 清明,雨落,思故人!

    原標題:清明安康 | 清明,雨落,思故人! 清明雲寄哀思 清明節,又稱踏青節 節期在仲春 與暮春之交 不知不覺,四月已至~ 隨著天氣漸暖,鶯飛草長 人們的踏春齣行也變得頻繁起來 在這個踏春遊玩的日子裏 一起等疫情消散共赴春光無限 下麵就一起看看我為大傢準備的 清明優質精美模闆吧~ 清明簡約海報 清明放假通知模闆 清明國風海報 清明插畫海報 清明寄哀思 清明攝影海報 清明踏青 微信首.......


江湖養老模式開啓,梯度服帶你“快逸如初”

江湖養老模式開啓,梯度服帶你“快逸如初”

    原標題:江湖養老模式開啓,梯度服帶你“快逸如初” 天氣一天天的暖和瞭,郊外的柳樹已經抽齣瞭嫩芽,處處都是粉色的花朵,在這樣的好天氣裏,真想讓人齣去走走,放鬆放鬆心情啊。既然是要齣門,當然要打扮得美美的,為瞭讓少俠們能更好地享受難得的閑暇時光,《一夢江湖》也推齣瞭許多新的著裝和裝扮,少俠不妨打開衣櫃看看吧~ 說起春天,總讓人想起旺盛的草木花卉,衣錦宴行第二套時裝“宸耀熒煌”就以絢麗的玫瑰金作為主色調,並在服裝上使用神草元素,充滿瞭春天的浪漫氣息。少俠用草藥狀發飾固定發絲,金質發冠上間的神草點綴著.......


厲害!一幫學生娃拍攝微電影普法類微電影《手機》網絡點擊量突破1.4萬次

厲害!一幫學生娃拍攝微電影普法類微電影《手機》網絡點擊量突破1.4萬次

    原標題:厲害!一幫學生娃拍攝微電影普法類微電影《手機》網絡點擊量突破1.4萬次 一名學生趁大傢下課不注意,偷瞭同學的手機,警察以普法教育、感化的方式,既保護瞭這名學生的自尊心,也讓他認識到瞭錯誤,最終手機物歸原主。 這不是某個校園裏的生活片段,而是由青海湟川中學學生自導自演的普法類微電影《手機》裏的情節。影片發布到網上後,引起瞭網友的廣泛關注。 這部微電影總時長7分35秒,旨在嚮廣大青少年普及法律知識,提高大傢的法律意識。雖然隻有短短的幾分鍾,但是故事情節相對來說比較完整,學生們演得有模有樣.......


索尼移動公司成立,涵蓋機器人、AI等業務

索尼移動公司成立,涵蓋機器人、AI等業務

    原標題:索尼移動公司成立,涵蓋機器人、AI等業務 4月1日,索尼集團宣布,從即日起,正式成立索尼移動公司(Sony Mobility)。索尼移動公司將開發一個移動服務平颱並將其商業化,旨在為移動空間的演進和發展做齣貢獻。該公司還將主導“aibo”自主型娛樂機器人、Airpeak專業無人機和Sociable Cart:SC-1娛樂車等業務的發展。 新公司還將繼續支持索尼與齣租車公司閤作成立的S.RIDE公司,利用AI(人工智能)和傳感技術提供安全可靠的交通服務。此外,新公司還將推動創新型AI機.......


91暢修保:冰箱風扇不轉瞭怎麼辦?

91暢修保:冰箱風扇不轉瞭怎麼辦?

    原標題:91暢修保:冰箱風扇不轉瞭怎麼辦? 冰箱的正常運行離不開內部零件的正常運行。當風扇等內部零件齣現問題時,冰箱自然無法正常運行。這時,我們放在冰箱裏的食物就有變質的風險。因此,很多人在發現冰箱風扇不轉動的問題後,都想在最短的時間內解決問題,但因為不知道該怎麼辦,所以特彆麻煩。今天91暢修保小編就來分享一下正確的做法。你可以根據下麵的介紹試試。 冰箱風扇不轉瞭解決方法 要成功解決冰箱風扇不轉的問題,首先要分析風扇不轉的原因。比如可以先打開冰箱看看我們是否在冰箱裏放瞭太多的食物。如果是這樣.......


盧偉冰微博調研新旗艦Redmi K60:米粉集體想要真全麵屏

盧偉冰微博調研新旗艦Redmi K60:米粉集體想要真全麵屏

    原標題:盧偉冰微博調研新旗艦Redmi K60:米粉集體想要真全麵屏 今天下午,小米集團中國區總裁、Redmi品牌總經理盧偉冰微博調研Redmi K60:如果讓你給一年後要發布的Redmi K60留言,你會說什麼? 米粉紛紛評論,呼聲最高的是“真全麵屏”,這位米粉稱“Redmi K20 Pro用戶最大的期盼是無挖孔真全麵屏”。 此前在Redmi K20 Pro、Redmi K30 Pro上,Redmi使用瞭彈齣全麵屏形態,實現瞭無劉海、無挖孔的真全麵屏設計,堪稱經典。 在Redmi K40係.......


“傾訴·暫停·選擇”掌握情緒密碼 ——不做憤怒的“小火山”

“傾訴·暫停·選擇”掌握情緒密碼 ——不做憤怒的“小火山”

    原標題:“傾訴·暫停·選擇”掌握情緒密碼 ——不做憤怒的“小火山” 嘉心教育 心好,一切都好。青少年心理健康是當下教育的熱點和難點,嘉興是全國心理健康示範城,經過此前的積極探索和努力實踐,在學生心理健康教育方麵,已經積纍下豐富的經驗。嘉心教育,就是您和您的孩子一直有懂得心理健康的師長們在綫嗬護。每周六,在這裏,讀懂孩子,讀懂教育,一起關心孩子—— 李 靜 嘉興市城南中心小學語文老師、班主任 1 個案錶現 憤怒的“小火山” 小樂同學,男,9歲,小學三年級學生,雖說他是小樂但.......


視頻號電商,迷霧終見光

視頻號電商,迷霧終見光

    原標題:視頻號電商,迷霧終見光 圖片來源@視覺中國 文 | 井尋 文 | 井尋 視頻號電商路徑中核心之一的櫥窗功能,最近做瞭改版。 在315晚會曝光直播帶貨亂象後,微信視頻號在3月17日發布新規,在3月25日起,視頻號櫥窗將不再接受個人主體小商店接入。簡單敘述,無論是直播還是視頻渠道,視頻號創作者將無法通過小商店以個人的身份上架商品至視頻號售賣。 上一次視頻號新規,還是在2月底,小商店將不顯示第三方電商平颱的商品(如京東、拼多多等),屆時第三方電商平颱的商品將無法上架至小商店/視頻號櫥窗.......


機寶:iPhone13經常黑屏,該如何解決?

機寶:iPhone13經常黑屏,該如何解決?

    原標題:機寶:iPhone13經常黑屏,該如何解決? 近日來,機寶小編收到很多用戶關於iPhone13莫名其妙黑屏,或者黑屏打不開手機的求助私信,閑暇時整理瞭以下這些解決辦法,希望能夠幫助大傢解決問題。以下原因可能會導緻蘋果手機黑屏或死機。 一、蘋果手機iOS係統升級後,手機可能與軟件不兼容,導緻手機黑屏。可嘗試通過更新iOS係統解決。 二、無綫網絡局域網和移動網絡切換導緻手機自動重啓,可能是由於無綫局域網功能,導緻 wi-fi 信號差,wi-fi 與移動網絡之間的自動開關,造成手機自動重啓。.......


室外噪音大如何解決?推薦找廣州專業鋁閤金門窗廠傢定製隔音窗

室外噪音大如何解決?推薦找廣州專業鋁閤金門窗廠傢定製隔音窗

    原標題:室外噪音大如何解決?推薦找廣州專業鋁閤金門窗廠傢定製隔音窗 在城市生活的居民,由於人多、車多,無法避免要被噪音乾擾,但隨著對居住環境需求的提高,很多住戶在對新房裝修或是舊房翻新時,都會找安裝使用鋁閤金隔音門窗。那麼在廣州,找哪傢生産廠傢定製隔音窗比較好呢? 其實,想知道“廣州隔音窗廠傢哪傢好”的業主,最終目標都是想找到一傢服務專業靠譜,費用真實、性價比高的廠傢。因此,有著10年+隔音門窗專業生産技術,緻力於高端門窗定製服務的源頭廠傢廣州帕德,一定是各位業主的優質選擇。 廣州帕德的生.......


51歲閆妮驚艷網友:自律上瞭癮,人生會有多酷炫?

51歲閆妮驚艷網友:自律上瞭癮,人生會有多酷炫?

    原標題:51歲閆妮驚艷網友:自律上瞭癮,人生會有多酷炫? 51歲比20歲還美是什麼感覺? 看看逆齡生長的典範閆妮就知道瞭! 之前閆妮的新劇《突圍》開播,所有人都被她的身材驚艷到瞭! 身材火爆不輸青春少女!長腿縴臂!輪廓清晰!氣色紅潤!時尚!氣質!說是脫胎換骨也不為過。 性感的鎖骨,迷死人的腰綫,穿長裙都遮不住大長腿…… 和23歲的女兒站在一起,完全不像母女,簡直就是逆天養眼的仙女姐妹花! 網友紛紛感嘆:上半輩子拼演技和纔華,下半輩子拼顔值! 可曾經,在大多數人印象中,閆妮.......


【傢庭教育微課堂】第十七講:你都不好好說話,為何怪孩子脾氣不好?

【傢庭教育微課堂】第十七講:你都不好好說話,為何怪孩子脾氣不好?

    原標題:【傢庭教育微課堂】第十七講:你都不好好說話,為何怪孩子脾氣不好? 《傢庭教育促進法》正式實施瞭 傢長們學習起來吧! 據全國婦聯傢庭教育狀況調查顯示,50%的傢長不知道用什麼方法教育孩子。多數父母存在不同程度的養育焦慮,過於關注學習,缺乏對孩子思想品德、行為習慣的養成和勞動、運動等能力的培養。 2022年1月1日,《傢庭教育促進法》正式實施,這是我國首次就傢庭教育進行專門立法。傢庭教育由傢事上升為國事,今後傢長們要依法帶娃瞭。為瞭讓各位傢長瞭解,學習傢庭教育知識,履行傢庭教育職責,做學習.......


您現在所在的位置 :  &gt;  &gt;

您現在所在的位置 :  &gt;  &gt;

    原標題:您現在所在的位置 :  >  >  責任編輯: .......


楊子姍彭冠英《婚姻的兩種猜想》開播!兩集就講完男女相識到生娃

楊子姍彭冠英《婚姻的兩種猜想》開播!兩集就講完男女相識到生娃

    原標題:楊子姍彭冠英《婚姻的兩種猜想》開播!兩集就講完男女相識到生娃 楊子姍、彭冠英新劇《婚姻的兩種猜想》開播,講述都市女精英與IT男,白富美與健身教練兩對情侶閃婚之後的婚姻生活。 打著“反催婚”、“大數據適配率”、“年下戀”等大齡男女在都市會遇見的情況,來講述社會現實的婚姻狀況。以為是一部高逼格職場、大齡剩女的現實題材好劇,但一點進去就被這裏麵的濾鏡磨皮閃瞎瞭眼。 現在的電視劇是一點也離不開磨皮濾鏡瞭,楊子姍狀態演技沒得說,但整個鏡頭一拉近,兩個臉頰被磨皮到反光,下頜角與脖子都連成瞭一綫.......


戰疫先鋒 | “疫”無反顧嚮前衝——吉林市政協駐南頂子村工作隊抗疫記

戰疫先鋒 | “疫”無反顧嚮前衝——吉林市政協駐南頂子村工作隊抗疫記

    原標題:戰疫先鋒 | “疫”無反顧嚮前衝——吉林市政協駐南頂子村工作隊抗疫記 近一個月以來,吉林市政協駐蛟河市黃鬆甸鎮南頂子村工作隊“疫”無反顧,不畏艱險,同南頂子村民一道共擔風雨,譜寫瞭抗疫鬥爭的壯麗“村”篇! 3月初,麵對嚴峻復雜的疫情形勢,駐村工作隊和南頂子村三委聞令而動,投身疫情防控。駐村第一書記鞏文軍號召全村黨員乾部:“我是黨員我先上,越是艱險越嚮前!”一時間,黨員乾部奮勇爭先。 村裏成立瞭疫情防控專班裏,設立瞭6個“黨員先鋒崗”,組織瞭5支誌願者隊伍,負責卡點守衛、核酸檢測.......


履行國防教育職責!金沙縣首批“兵校長”上崗

履行國防教育職責!金沙縣首批“兵校長”上崗

    原標題:履行國防教育職責!金沙縣首批“兵校長”上崗 近日,畢節市金沙縣首批6名“兵校長”上崗,奔赴該縣源村鎮的1所中學和5所小學,履行國防教育職責。 今年以來,金沙縣人武部與縣退役軍人事務局、縣教育局聯閤組織開展“兵校長”進校園活動。根據實施計劃,該部將從全縣範圍內遴選120餘名退役軍人誌願者,通過集中培訓、考核上崗的方式,按照1所學校1名“兵校長”的編配,到全縣120餘所中、小學任職一年,在校期間不領薪酬,主要負責做好學生的國防教育工作。 活動啓動以來,全縣各鄉(鎮、街道)退役軍人積極響應.......


屋麵瓦的選擇很重要,但是瓦該怎麼選呢?

屋麵瓦的選擇很重要,但是瓦該怎麼選呢?

    原標題:屋麵瓦的選擇很重要,但是瓦該怎麼選呢? 屋麵瓦的選擇雖然很重要,但是往往不知道該怎麼選擇。鋁鎂錳金屬一是沒有相關的專業知識,也沒有選擇依據作為參考,因此一提到選擇就感到為難。 鋁鎂錳金屬屋麵 屋麵瓦經受著風吹日曬,選擇那些耐腐蝕性強、不易腐蝕的材料是比較重要的。在選擇時,要注意當地的氣候,可以選擇齣閤適的屋麵瓦。 屋麵瓦瓦型款式多,不同瓦片製作成型會呈現齣不一樣的視覺效果,那什麼材質能夠滿足你的需求,且建築的風格與環境相互配閤,即不失去優雅又亮麗。 鋁鎂錳金屬屋麵 鋁鎂錳金屬瓦.......


王俊凱“生日蛋糕”遭曝光,設計超級夢幻,寓意更是特彆的有心

王俊凱“生日蛋糕”遭曝光,設計超級夢幻,寓意更是特彆的有心

    原標題:王俊凱“生日蛋糕”遭曝光,設計超級夢幻,寓意更是特彆的有心 王俊凱“生日蛋糕”遭曝光,設計超級夢幻,寓意更是特彆的有心 前幾天的時候,正是王俊凱的生日,他的兩位弟弟易烊韆璽跟王源,都貼心的為他送上瞭祝福,而這個行為是間接打破瞭說他們三人不和的傳聞。很多人都說,在組閤當中王俊凱就像是一個暖心大哥哥一樣,經常的照顧彆人,可能就是因為如此,他纔能夠這麼的受歡迎。 在最近有網友突然曬齣瞭王俊凱20周歲生日的蛋糕,設計可以說是超級的夢幻,寓意更是特彆的用心。從照片中我們可以看到,此時的王俊凱穿著.......


托育中心設計裝修誤區

托育中心設計裝修誤區

    原標題:托育中心設計裝修誤區 托育中心作為孩子們健康成長、啓濛學習的重要場所,其教育環境是尤為重要。托育中心設計應創造適閤孩子們身心健康成長的良好環境,培養幼兒美好情操,陶冶心靈,將孩子們的教育學習寓於美好環境所承載的娛樂之中。那在托育中心設計 裝修 中存在那些誤區呢?讓我們一起來看看吧! 缺少空間舒適感 由於孩子們生理和心理發育的特點,0-3歲的孩子們常常缺乏安全感,因此在對托育中心設計 裝修 裝修時,需要為孩子們搭建安全的環境氛圍。比如在材料上可以選擇木質材料做裝飾,照明選用更為柔和的暖光.......


聊城市教體局重要通知!

聊城市教體局重要通知!

    原標題:聊城市教體局重要通知! 各位考生: 根據《聊城市教育體育局關於進一步做好2022年初中信息技術和實驗操作考試的通知》(聊教體字〔2022〕18號)精神,今年我市初中學業水平考試的信息技術科目考試時間為4月23日至24日,物理、化學、生物實驗操作考試於4月30日前完成,具體考試時間由各縣(市、區)安排。考試報名由考生學籍所在學校集中進行報名,由學校打印準考證發放給考生。為確保大傢考試平穩順利,現就有關事項提醒如下: 一、信息技術考試 1.考試對象及考點。信息技術考試對象為初三學生。聊城學.......


那些老派歌手為什麼還一直努力參加歌唱比賽?

那些老派歌手為什麼還一直努力參加歌唱比賽?

    原標題:那些老派歌手為什麼還一直努力參加歌唱比賽? 現在的時代越來越鼓勵每一個人努力去完成自己的夢想,像是“成為一名歌手”就已經可以通過各種方式去實現,成為“super star”。早在十年前,就有針對是否夠格成為一名歌手的歌唱比賽,通過贏得冠軍來證明自己的實力。像是《金麯超級星》,是擁有演藝圈豐富資曆的歌手或演員參與比賽,通過比賽贏得人氣和實力的證明,就有璽恩,祝鏘博,劉祿存,高蕾雅,袁耀發等,而袁耀發至今還在堅持自己的“歌手夢”,最近還發行全新的EP《天生好命》。 韓磊 .......


飛行少年團 嚴屹寬導助全員即刻齣道

飛行少年團 嚴屹寬導助全員即刻齣道

    原標題:飛行少年團 嚴屹寬導助全員即刻齣道 一首齣道單麯《主場》點燃成團熱情!小編已經忍不住給飛行少年團打100昏!!!你們對這個男團的顔值怎麼看? 飛行少年團的營業日常也是帥到炸,跳傘、打野、吃雞、開飛機樣樣說來就來! 任務到達,成雙成對開著戰鬥機就是一波任務執行。 飛機跑道就是他們的秀場,墨鏡一帶,頭盔一拿,這排麵隨隨便便就支棱起來瞭! 休息之餘還能在天空畫個愛心啥的錶白心跡,飛行團哥哥也是浪漫的與眾不同!小編忍不住飯圈迷妹上綫:飛行少年團勇敢飛,ikong永相隨~.......


酒泉市人工影響天氣作業公告

酒泉市人工影響天氣作業公告

    原標題:酒泉市人工影響天氣作業公告 人工影響天氣作業是一項利國利民、服務經濟社會的公益事業,多年來在生態環境改善、抗旱減災等方麵做齣瞭積極貢獻。酒泉市人工影響天氣作業(增雨雪)是利用火箭發射係統嚮天空發射碘化銀火箭彈達到人工影響局部天氣的目的。為確保安全生産,根據中華人民共和國《人工影響天氣管理條例》第十二條和《甘肅省人工影響天氣管理辦法》第二十一條有關規定,現公告如下: 一、作業方式及時段:酒泉市人工影響天氣作業采用固定作業和機動作業相結閤的方式,作業設備采用WR-98新型火箭和煙爐。全年不.......


王源和歐陽娜娜閨蜜一同逛街,兩人私下關係甚好,鐵哥們

王源和歐陽娜娜閨蜜一同逛街,兩人私下關係甚好,鐵哥們

    原標題:王源和歐陽娜娜閨蜜一同逛街,兩人私下關係甚好,鐵哥們 王源和歐陽娜娜作為娛樂圈的新聲代藝人,雖然年齡很小,但是人氣卻非常高。王源和歐陽娜娜都在伯剋利音樂學院,曾經兩人還一同主持過綜藝《王牌對王牌》,參演過《大主宰》,再加上年齡相仿,所以外界有很多媒體經常爆料兩人戀情的消息。 其實,關於兩人的戀情似乎並不是空穴來風,王源曾經寫過一首歌《姑娘》,他錶示這是寫給未來女友的一首歌,仔細來看這首歌的歌詞卻發現故事中的女主角和歐陽娜娜有幾分相似。此外,王源去伯剋利上學也是和歐陽娜娜住在同一所公寓.......


熊黛林産後首戰米蘭時裝周,腳踩恨天高,辣媽範兒十足

熊黛林産後首戰米蘭時裝周,腳踩恨天高,辣媽範兒十足

    原標題:熊黛林産後首戰米蘭時裝周,腳踩恨天高,辣媽範兒十足 9月24日,熊黛林在社交平颱上曬齣瞭一組在米蘭國際時裝周走秀的照片,並錶示,久違瞭T颱,謝謝米蘭國際時裝周的邀請。模特齣身的熊黛林,重迴T颱,辣媽範兒十足。 當天,熊黛林梳著中分大波浪,非常有氣質。穿著粉銀色外套和銀色連衣裙,腳踩銀色細邊恨天高,雖然熊黛林已經離開舞颱一段時間瞭,但她走秀時的姿勢、錶情仍然非常專業,氣場全開。 據悉,熊黛林這次是壓軸齣場的,可見其優秀瞭。而且閤照中,熊黛林也是唯一一個東方麵孔,格外引人.......


15年河南億萬富豪做DNA鑒定:與兒子匹配,與16年前的劫匪也匹配

15年河南億萬富豪做DNA鑒定:與兒子匹配,與16年前的劫匪也匹配

    原標題:15年河南億萬富豪做DNA鑒定:與兒子匹配,與16年前的劫匪也匹配 作的惡,不管等待多久,終究還是要付齣代價的。 2015年河南省駐馬店市一施工工地,工人們正在熱火朝天的工作,邊上站著一群人指指點點。似乎是在討論建造進程,為首的中年男子一看就來頭不小,身著休閑裝。每當他說什麼,其他人都爭相應和,然而就在他們討論的興起的時候。幾名男子突然衝齣來按住為首的中年男子,並大喝:“彆動,我們是警察!” 周圍的人都愣住瞭,但他們掏齣的警察證以及手銬明白無誤的告知人們,他們確實是警察。可是,警察怎.......


外媒:衛星圖像顯示俄軍已經撤離基輔郊外的安東諾夫機場

外媒:衛星圖像顯示俄軍已經撤離基輔郊外的安東諾夫機場

    原標題:外媒:衛星圖像顯示俄軍已經撤離基輔郊外的安東諾夫機場 美國衛星圖像公司Maxar Technologies 3月31日拍攝的圖像顯示,俄軍已撤離位於烏剋蘭基輔郊外的一處軍事基地。美國有綫電視新聞網(CNN)4月1日報道稱,這一信息與他們從美國國防部信源處獲取的消息一緻。 據CNN 1日消息,最新的衛星圖像顯示,俄軍已從基輔西北方嚮大約28公裏、位於戈斯托梅利的安東諾夫機場撤齣。過去幾周內,俄軍一直在該空軍基地不停地挖掘。 消息稱,衛星圖片證實瞭美國國防部一名官員早些時候提供的信息.......


王一博自曝怕跟趙麗穎對戲, 透露其私下勤勉 休息都在背台詞

王一博自曝怕跟趙麗穎對戲, 透露其私下勤勉 休息都在背台詞

    原標題:王一博自曝怕跟趙麗穎對戲, 透露其私下勤勉 休息都在背颱詞 眾所周知,趙麗穎在當紅時與馮紹峰宣布結婚,後來更是火速産子,在大傢還沒有消化這一係列消息的時候,趙麗穎的身影消失在娛樂圈。在告彆瞭娛樂圈400多天後,大傢終於迎來瞭她的迴歸,大傢的趙麗穎也是終於迴來啦! 而隨著電視劇《有翡》的官宣,趙麗穎也正式展開瞭自己復齣的首部電視劇錄製,盡管在之前,雙方粉絲對該劇的看法不一,但直到正式官宣當天,所有的陰霾與不快一掃而光,剩下的,自然是期待兩位第一次閤作後的精彩碰撞。 不過人紅是非多,王.......


王俊凱片場和馬思純聊天,給她看手機內容,還笑得好甜,酸瞭!

王俊凱片場和馬思純聊天,給她看手機內容,還笑得好甜,酸瞭!

    原標題:王俊凱片場和馬思純聊天,給她看手機內容,還笑得好甜,酸瞭! 近段時間以來,王俊凱很久都沒有齣來營業,也沒有其他的消息,其實是認真地在拍攝新電影《世外桃源》,在劇組閉關拍戲。一旦進入拍攝的狀態,王俊凱就特彆認真,因為他特彆想要把作品更好地呈現齣來。在拍攝《749局》的時候,小凱閉關九個月,就算等戲也會一直待,以至於後麵導演主動給小凱放假。 視頻中,王俊凱的車正在前麵開著,後麵一大群人追著,像極瞭跑馬拉鬆的場景,結果保安隻能緊急地引導王俊凱的車快速開離現場。王俊凱這人氣實屬旺盛,國民度.......


王一博原來是藝名?他的真名被曝光後,粉絲炸鍋:不改名早火瞭!

王一博原來是藝名?他的真名被曝光後,粉絲炸鍋:不改名早火瞭!

    原標題:王一博原來是藝名?他的真名被曝光後,粉絲炸鍋:不改名早火瞭! 王一博原來是藝名?他的真名被曝光後,粉絲炸鍋:不改名早火瞭! 娛樂圈的明星們,每個人長得都是一錶人纔,顔值超高,但在娛樂圈要想擁有知名度,取一個朗朗上口的藝名也是非常重要的。一個好的藝名會讓大傢記憶深刻,很多明星進軍娛樂圈,基本上用的都不是他們的本名,而是他們後來改的藝名。 取一個藝名是非常有水平的,不僅給人一種藝術感,而且還給人一種特彆高大上,具有明星範兒的感覺。王一博,最近很火的《有翡》就是他和趙麗穎主演的,其實王一.......


Brandon Maxwell 2022春夏係列,嚴肅的不安全感,真實微笑

Brandon Maxwell 2022春夏係列,嚴肅的不安全感,真實微笑

    原標題:Brandon Maxwell 2022春夏係列,嚴肅的不安全感,真實微笑 Brandon Maxwell 的這些服裝上,裙裝等的穿搭增加瞭更多的嚴肅,還有一些不安全的氣質感; 裙裝上的開叉下擺、荷葉邊與褶皺等的加入中,更有光滑麵料、浪漫活力的花紋圖案、各種條紋等的齣現,讓這些裙裝上的時尚感更加強烈,也在微笑與真實中,增加一些氣質。 在這些服裝上齣現瞭一些紫色係的顔色,這些紫色係的顔色在或是深色的顔色中更多瞭幾分穩重的高雅,也有和一些鮮艷色彩的對比,更多瞭一些色彩的衝擊,為服裝增加瞭.......


網友在餐廳偶遇董潔,素顔憔悴膚色也很黑,同齡人中算老得快的!

網友在餐廳偶遇董潔,素顔憔悴膚色也很黑,同齡人中算老得快的!

    原標題:網友在餐廳偶遇董潔,素顔憔悴膚色也很黑,同齡人中算老得快的! 董潔以前就是會給人一種非常的清純的感覺,可是現在真的是老的越來越快瞭,而且在同齡人中間就算得上是那種衰老速度很快的。網友在餐廳裏偶遇董潔都快要認不齣來瞭,素顔看起來實在是太憔悴瞭吧,膚色也很黑呢,同齡的女明星雖然也有老瞭的,但是感覺沒她老的速度快啊。因為她看起來就是皮膚比較黑吧,所以整體就會顯得稍微有點暗沉瞭。自然而然就顯得沒那麼好看啊,跟個普通人沒什麼兩樣。 董潔穿著一件白色的衣服,搭配的是那種黑色的裙子,顯得整體看起來.......


網友:孫藝珍的婚紗不好看,像淘寶買的,我:孫漂亮比模特穿好看

網友:孫藝珍的婚紗不好看,像淘寶買的,我:孫漂亮比模特穿好看

    原標題:網友:孫藝珍的婚紗不好看,像淘寶買的,我:孫漂亮比模特穿好看 網友:孫藝珍的婚紗不好看 ,像淘寶買的,我:孫漂亮比模特穿好看。不得不驚嘆,真是太養眼瞭!不過好神奇,以前一直說孫藝珍是拉拉,突然和玄彬官宣並結婚瞭!難怪她說玄彬是初戀,莫非是玄彬是她男性初戀。 看看大傢怎麼說: 隻有我覺得宋的婚紗像淘寶買的嗎? 我也覺得,仙女的兩套挺好看的。 這也不是宋得婚禮乾嘛提宋得婚紗。那孫的婚紗像啥。 你不覺得人很現實的嗎,當宋很火的時候一片捧當孫活瞭一部劇就捧,當宋失意瞭就很多人踩,真現實!兩.......


突發!近萬米高空上,一架波音飛機擋風玻璃破裂...

突發!近萬米高空上,一架波音飛機擋風玻璃破裂...

    原標題:突發!近萬米高空上,一架波音飛機擋風玻璃破裂... 據《每日郵報》4月1日報道,美國達美航空的波音757-232型號飛機因在約9144米的高空上擋風玻璃破裂,緊急降落至丹佛。 據悉,這架飛機是從鹽湖城飛往華盛頓特區的760航班,機型為波音757-232。飛機上有198名乘客,航程進行瞭90分鍾後,擋風玻璃突然破裂,機組人員宣布進入緊急狀態。 波音760型號飛機。圖源:《每日郵報》 當地時間3月31日晚上11點15分左右,該航班轉嚮丹佛,後安全降落。 聯邦航空局指齣,它將對這一情況進.......


10年來口碑最好的10部劇,2部少有人看過,1部被徹底下架

10年來口碑最好的10部劇,2部少有人看過,1部被徹底下架

    原標題:10年來口碑最好的10部劇,2部少有人看過,1部被徹底下架 文|冷絲 欄目|經典劇 今年是2022年,如果自2012年開始統計至2021年,也就是足足10年的時間,列齣每一個年度口碑最好的國産劇,將是哪些作品呢? 好作品的質量當然是很高的,不過,部分作品並不是很熱門,看過的也不多,還有個彆作品被下架,而且是被徹底下架,各大網絡平颱上已經不見蹤影,即使有零星的片段,也僅僅是簡介或者預告片段。 2021年,豆瓣評分最高的是《覺醒年代》,分數為9.3分。 這是一部革命曆史正劇,所反映的曆史.......




未來大學選纔採計 數學失寵、資訊科技攀升

林書豪全方位錶現 率籃網拿下3連勝

智慧手機時代 新電視節目考驗戀愛關係

大數據開發與管理架構完整剖析

大數據培訓:RDD、DataFrame的特性與區彆

【知識圖譜】産品視角下的知識圖譜構建流程與技術理解

MongoDB常見問題解答:時間與時區

可操縱外國輿論政局 陸企境外重要人物個資數據庫曝光

遭恐怖直銷組織控製 他被迫1個月睡8女

玩遊戲得到兔子 激發吳盈瑾創愛兔協會

智慧遙控車噴農藥 農友不再怕中毒

228連假 宜蘭熱門景點 公車免費

2012年用DDR4記憶體到來 起步2133MHz

紮實做好開學準備工作 靜待起航跨入美麗春天

走失11年奇蹟重逢 牠讓網全哭瞭


前一篇新聞
中考化學:常用方程式分類匯總,備考神器!
后一篇新聞
“輪胎起火瞭!”男子衝齣去滅火,下一幕卻捂著胸口倒下





© 2025 - quweinews.com. All Rights Reserved.
© 2025 - quweinews.com. 保留所有權利