Mysql常用知識3：Kafka和數據庫優化

文章目錄

      • 一、分布式消息系統（Kafka相關問題5-10）
        • 5. Kafka如何保證消息不丟失？
        • 6. 項目中Kafka具體怎么使用的？
        • 7. 消息異常未發送成功怎么解決？
        • 8. 重試具體怎么做的，循環嗎？
        • 9. 重試多次失敗怎么辦，拋出異常嗎？
        • 10. 消息一直沒發出去是什么原因？
      • 二、數據庫設計與優化（問題11-18）
        • 11. SQL怎么優化？
        • 12. 怎么判斷是慢查詢？
        • 13. 怎么設計一個好的數據庫？
        • 14. 項目中數據庫表怎么設計的？
        • 15. 主鍵怎么設計？普通遞增 vs 分布式雪花算法
        • 16. 除了雪花算法和UUID，還有什么主鍵不重復方案？
        • 17. 具體字段類型設計：用戶名用什么類型？
        • 18. 什么時候用到JOIN？
      • 三、加密算法（問題19-20）
        • 19. 左連接、右連接、外連接的區別？
        • 20. 加密算法有哪些，什么區別？

以下是針對您提出的20個問題的詳細解答，分為分布式消息系統（Kafka）、數據庫設計與優化、加密算法三個模塊：

一、分布式消息系統（Kafka相關問題5-10）

5. Kafka如何保證消息不丟失？

Kafka通過生產者、Broker、消費者三端機制確保消息不丟失：

  • 生產者端：
    • 設置 acks=all（或 acks=-1）：等待所有ISR副本確認接收消息。
    • 啟用 retries 重試機制（默認10次），處理網絡抖動等臨時錯誤。
    • 記錄 producer.send() 返回的 RecordMetadata，用于故障后重試（需避免冪等性問題，可通過 enable.idempotence=true 開啟冪等生產者）。
  • Broker端：
    • 副本機制：消息寫入分區的Leader副本后，需等待ISR（In-Sync Replicas）中的Follower副本同步完成才標記為“已提交”。
    • 持久化：消息寫入磁盤時使用fsync強制刷盤（可通過log.flush.interval.messages等參數控制）。
  • 消費者端：
    • 手動提交offset：關閉自動提交（auto.commit.offset=false），確保消費成功后再提交。
    • 重復消費處理：通過業務層去重（如利用消息唯一ID+Redis存儲已消費記錄）。
6. 項目中Kafka具體怎么使用的？

典型應用場景：

  • 異步解耦：訂單系統下單后，通過Kafka通知庫存、物流、支付等系統，避免同步調用超時。
  • 流量削峰：秒殺活動中，將用戶請求寫入Kafka，消費者（如Java服務）按限流速度處理，防止數據庫被瞬時流量沖垮。
  • 日志采集：將應用日志發送到Kafka，供ELK（Elasticsearch+Logstash+Kibana）或Flink等系統進行實時分析。

代碼示例（Java生產者）：

Properties props = new Properties();
props.put("bootstrap.servers", "kafka:9092");
props.put("acks", "all");
props.put("retries", 3);
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");KafkaProducer<String, String> producer = new KafkaProducer<>(props);
ProducerRecord<String, String> record = new ProducerRecord<>("order-topic", "123", "{\"orderId\":\"1001\",\"amount\":1000}");try {producer.send(record, (metadata, exception) -> {if (exception != null) {log.error("消息發送失敗：{}", exception.getMessage());} else {log.info("消息已發送至分區{}，偏移量{}", metadata.partition(), metadata.offset());}});
} finally {producer.close();
}
7. 消息異常未發送成功怎么解決？

排查步驟：

  1. 生產者日志：查看是否有網絡異常（如org.apache.kafka.common.errors.NetworkException）、分區不存在等錯誤。
  2. Broker狀態：檢查Kafka集群是否正常（節點存活、分區Leader是否存在），使用kafka-topics.sh --describe查看分區ISR狀態。
  3. 重試機制：若為臨時性錯誤（如分區負載過高），通過retries自動重試；若為永久性錯誤（如消息格式錯誤），需捕獲異常并記錄到死信隊列（Dead Letter Queue，DLQ）。
  4. 監控告警：通過Prometheus+Grafana監控producer_request_error_rate等指標，及時發現發送失敗趨勢。
8. 重試具體怎么做的，循環嗎？
  • Kafka內置重試：
    生產者通過retries參數設置重試次數（默認10次），每次重試間隔由retry.backoff.ms控制（默認100ms）。重試邏輯為指數退避（如第1次重試間隔100ms，第2次200ms，避免頻繁重試加劇網絡負載）。
  • 業務層重試：
    若內置重試耗盡仍失敗，可將消息存入數據庫（如MySQL）或Redis，通過定時任務（如Spring Task）或分布式調度框架（如Elastic-Job）進行循環重試，直至成功或標記為“需要人工處理”。
9. 重試多次失敗怎么辦，拋出異常嗎？
  • 有限重試后終止：
    設定最大重試次數（如5次），超過后不再自動重試，而是：
    1. 發送告警（郵件/短信通知運維人員）。
    2. 將消息寫入死信隊列（如Kafka的dead-letter-topic），供人工排查（如消息格式錯誤、下游系統故障）。
  • 異常處理：
    在生產者的回調函數中捕獲最終異常，記錄詳細日志（如消息內容、失敗原因），但不建議直接拋出異常中斷業務流程，應保證主流程繼續運行，僅對失敗消息做異步處理。
10. 消息一直沒發出去是什么原因？

常見原因分析：

  • 網絡問題：
    • 生產者與Broker之間網絡斷開（如防火墻攔截、VPN中斷）。
    • Broker節點負載過高，無法處理新請求（可通過kafka-consumer-groups.sh查看分區Lag）。
  • 元數據問題：
    • 生產者未正確獲取分區元數據（如首次連接時未等待metadata.max.age.ms刷新）。
    • 主題被刪除或分區數變更，導致生產者緩存的元數據失效。
  • 配置錯誤：
    • acks設置為0（不等待Broker確認），但網絡故障導致消息丟失。
    • 消息大小超過Broker限制（message.max.bytes默認1MB）。
  • 權限問題：
    • 生產者未被授予主題的寫入權限（如使用ACL認證時未正確配置）。
  • 下游系統故障：
    • 消費者組掛掉或消費速度過慢，導致分區積壓，Broker拒絕新消息寫入（需調整分區數或消費者并行度）。

二、數據庫設計與優化（問題11-18）

11. SQL怎么優化？

優化方向：

  1. 索引優化：
    • 為高頻查詢字段添加索引（如WHERE、JOIN、ORDER BY字段），避免全表掃描。
    • 避免過度索引（索引會增加寫入成本），使用EXPLAIN分析執行計劃，查看type是否為range/ref（優于ALL）。
  2. 分頁優化：
    • 大偏移量分頁（如LIMIT 100000, 10）性能差，可通過子查詢或WHERE id > last_id優化。
  3. 查詢語句優化：
    • 避免在索引字段上使用函數（如SELECT * FROM users WHERE YEAR(create_time) = 2023）。
    • 用EXISTS替代IN查詢子集（如SELECT * FROM A WHERE EXISTS (SELECT 1 FROM B WHERE B.a_id = A.id)）。
  4. 分庫分表：
    • 單表數據量超過500萬行時，可按業務維度（如用戶ID取模）拆分到多個庫/表。
12. 怎么判斷是慢查詢？

方法：

  • 開啟慢查詢日志：
    MySQL中通過SET GLOBAL slow_query_log = ON;開啟，設置long_query_time閾值（默認10秒，可調整為0.5秒）。
  • 監控工具：
    • 使用pt-query-digest分析慢查詢日志，統計執行頻率、平均耗時、鎖等待等。
    • 數據庫監控平臺（如Prometheus+MySQL Exporter）實時監控slow_queries指標。
  • 執行計劃分析：
    對疑似慢查詢執行EXPLAIN，查看：
    • type：ALL表示全表掃描，需優化索引。
    • rows：掃描行數是否過大（理論上應小于總數據量的5%）。
    • Extra：是否包含Using filesort（文件排序）或Using temporary（臨時表），這兩者通常性能較差。
13. 怎么設計一個好的數據庫？

設計原則：

  1. 需求分析：
    • 明確業務場景（如電商訂單、社交動態），識別核心實體（用戶、訂單、商品）及關系（一對一、一對多）。
  2. 范式設計：
    • 遵循3范式（如消除重復數據、確保依賴關系正確），但可適當反范式（如冗余字段）提升查詢性能。
  3. 字段設計：
    • 選擇合適的數據類型（如INT存儲用戶ID，VARCHAR(255)存儲用戶名），避免TEXT等大字段濫用。
    • 允許NULL的字段需添加默認值（如create_time DEFAULT CURRENT_TIMESTAMP）。
  4. 性能考量：
    • 主鍵設計：使用自增ID或雪花算法（分布式場景），確保主鍵查詢高效。
    • 分區分表：按時間（如按年/月分表）或業務維度拆分，降低單表數據量。
  5. 擴展性：
    • 預留字段（如extend_info JSON）應對未來需求變化，避免頻繁修改表結構。
14. 項目中數據庫表怎么設計的？

示例：電商訂單系統核心表

-- 用戶表
CREATE TABLE user (user_id BIGINT PRIMARY KEY AUTO_INCREMENT,  -- 自增主鍵username VARCHAR(50) NOT NULL UNIQUE,       -- 用戶名（唯一索引）password VARCHAR(64) NOT NULL,              -- 密碼（加密存儲）mobile CHAR(11) UNIQUE,                     -- 手機號（唯一索引）create_time DATETIME DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB CHARSET=utf8mb4;-- 商品表
CREATE TABLE product (product_id BIGINT PRIMARY KEY AUTO_INCREMENT,product_name VARCHAR(100) NOT NULL,category_id INT NOT NULL,                   -- 分類ID（外鍵關聯category表）price DECIMAL(10, 2) NOT NULL,              -- 價格（精確到分）stock INT NOT NULL DEFAULT 0
) ENGINE=InnoDB;-- 訂單表
CREATE TABLE order (order_id BIGINT PRIMARY KEY,                -- 雪花算法生成user_id BIGINT NOT NULL,                    -- 買家ID（外鍵）total_amount DECIMAL(10, 2) NOT NULL,status TINYINT NOT NULL DEFAULT 0,          -- 訂單狀態（0待支付，1已支付，2已發貨）create_time DATETIME DEFAULT CURRENT_TIMESTAMP,FOREIGN KEY (user_id) REFERENCES user(user_id)
) ENGINE=InnoDB;-- 訂單詳情表
CREATE TABLE order_detail (order_id BIGINT NOT NULL,                   -- 訂單ID（聯合主鍵）product_id BIGINT NOT NULL,                 -- 商品ID（聯合主鍵）quantity INT NOT NULL,price DECIMAL(10, 2) NOT NULL,PRIMARY KEY (order_id, product_id),FOREIGN KEY (order_id) REFERENCES order(order_id),FOREIGN KEY (product_id) REFERENCES product(product_id)
) ENGINE=InnoDB;
15. 主鍵怎么設計？普通遞增 vs 分布式雪花算法
  • 單庫場景：
    使用AUTO_INCREMENT自增主鍵，簡單高效，適合單節點數據庫。
  • 分布式場景：
    • 雪花算法（Snowflake）：生成64位唯一ID（時間戳+工作節點+序列號），支持高并發，如Java的Twitter雪花算法實現。
    • UUID：生成36位字符串（如550e8400-e29b-41d4-a716-446655440000），雖全球唯一但占用空間大，不適合作為主鍵（可作為業務唯一標識）。
16. 除了雪花算法和UUID，還有什么主鍵不重復方案？
  • 數據庫自增+分庫鍵：
    分庫場景下，為每個庫設置不同的自增起始值和步長（如庫1起始1，步長2；庫2起始2，步長2），確保跨庫唯一。
  • Redis生成ID：
    使用INCR命令原子性生成遞增ID，適合分布式系統，如：
    import redis
r = redis.Redis(host='localhost', port=6379)
order_id = r.incr('order_id_counter')
  • UUID變種：
    • UUID without hyphens：去掉連字符（如550e8400e29b41d4a716446655440000），節省空間。
    • ULID（Universally Unique Lexicographical Identifier）：比UUID更短（26字符），按字典序排列，適合索引。
17. 具體字段類型設計：用戶名用什么類型？
  • 推薦類型：
    • VARCHAR(n)：n根據業務需求設定（如VARCHAR(50)），存儲用戶名文本（支持中文、字母、數字混合）。
    • CHAR(n)：固定長度（如CHAR(20)），適合長度一致的場景（如學號），但浪費空間，不推薦用戶名。
  • 注意事項：
    • 字符集使用utf8mb4（支持Emoji和生僻字）：CREATE TABLE ... CHARSET=utf8mb4;
    • 唯一性約束：UNIQUE KEY(username)，避免重復注冊。
    • 密碼字段：絕不存儲明文，使用SHA-256+鹽值加密（如password VARCHAR(64) NOT NULL存儲哈希值）。
18. 什么時候用到JOIN？

適用場景：

  • 關聯多張表查詢數據（如查詢訂單對應的用戶姓名和商品信息）。
  • 替代子查詢，提升性能（如SELECT u.name, o.total_amount FROM user u JOIN order o ON u.user_id = o.user_id;）。

JOIN類型選擇：

  • INNER JOIN：僅返回兩張表中匹配的行（如用戶存在且訂單存在）。
  • LEFT JOIN：返回左表所有行，右表匹配不到的行用NULL填充（如查詢所有用戶及其訂單，包括未下單用戶）。
  • RIGHT JOIN：與LEFT JOIN相反，返回右表所有行，實際中較少使用，可用LEFT JOIN+表交換替代。
  • FULL OUTER JOIN（外連接）：返回左右表所有行，匹配不到的用NULL填充（MySQL不支持，需用LEFT JOIN UNION RIGHT JOIN模擬）。

三、加密算法（問題19-20）

19. 左連接、右連接、外連接的區別？
類型定義示例（表A: 用戶，表B: 訂單）
INNER JOIN僅返回A和B中ON條件匹配的行只返回有訂單的用戶
LEFT JOIN返回A的所有行，B中無匹配的行用NULL填充返回所有用戶，無訂單的用戶訂單字段為NULL
RIGHT JOIN返回B的所有行，A中無匹配的行用NULL填充返回所有訂單，無用戶的訂單（異常數據）字段為NULL
FULL OUTER JOIN返回A和B的所有行，無匹配的行用NULL填充（MySQL不支持）需用A LEFT JOIN B UNION A RIGHT JOIN B模擬
20. 加密算法有哪些，什么區別？

常見加密算法分類及對比：

類別算法名稱密鑰類型用途特點
對稱加密AES（AES-128/256）單密鑰數據加密（如敏感字段存儲、通信加密）速度快，密鑰需安全傳輸（常用作HTTPS底層加密）
DES/3DES單密鑰歷史系統兼容（已逐漸被AES取代）密鑰長度短（56位），安全性低
Blowfish單密鑰快速加密（如VPN）可變密鑰長度（32-448位），適合資源受限環境
非對稱加密RSA（2048/4096位）公鑰+私鑰數字簽名、密鑰交換（如HTTPS證書）安全性高，但速度慢，適合少量數據加密
ECC（橢圓曲線）公鑰+

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/diannao/85172.shtml
繁體地址，請注明出處：http://hk.pswp.cn/diannao/85172.shtml
英文地址，請注明出處：http://en.pswp.cn/diannao/85172.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

常見的RAG文檔解析輔助工具匯總及企業選型思考

常見的RAG文檔解析輔助工具匯總及企業選型思考

以下當前比較知名的RAG的文檔解析輔助工具的開源項目匯總&#xff0c;包含核心功能、License信息及GitHub地址&#xff1a; 1. RAGFlow 核心功能&#xff1a;支持PDF/掃描件/CAD等23種格式解析&#xff0c;OCR準確率98%&#xff0c;知識圖譜融合&#xff0c;混合檢索&#xf…
閱讀更多...
基于Sqoop的MySQL-Hive全量/增量同步解決方案（支持多表批量處理

基于Sqoop的MySQL-Hive全量/增量同步解決方案（支持多表批量處理

一、全量同步方案設計 1.1 基礎命令模板 sqoop import \ --connect jdbc:mysql://mysql_host:3306/db_name \ --username user \ --password pass \ --table source_table \ --hive-import \ --hive-table target_table \ --hive-overwrite \ # 覆蓋已有表 --num-mappers 8 …
閱讀更多...
前端學習（7）—— HTML + CSS實現博客系統頁面

前端學習（7）—— HTML + CSS實現博客系統頁面

目錄 一&#xff0c;效果展示 二&#xff0c;實現博客列表頁 2.1 實現導航欄 2.2 實現個人信息 2.3 實現博客列表 三&#xff0c;實現博客正文頁 3.2 復用 3.4 實現博客正文 四&#xff0c;實現博客登錄頁 4.1 版心 4.2 登錄框 五&#xff0c;實現博客編輯頁 5.1 …
閱讀更多...
【技能拾遺】——家庭寬帶單線復用布線與配置（移動2025版）

【技能拾遺】——家庭寬帶單線復用布線與配置（移動2025版）

&#x1f4d6; 前言&#xff1a;在家庭網絡拓撲中&#xff0c;客廳到弱電箱只預埋了一根網線&#xff0c;由于已將廣電的有線電視取消并改用IPTV。現在需要解決在客廳布置路由器和觀看IPTV問題&#xff0c;這里就用到單線復用技術。 目錄 &#x1f552; 1. 拓撲規劃&#x1f55…
閱讀更多...
VTK|實現類似CloundCompare的測量功能

VTK|實現類似CloundCompare的測量功能

文章目錄 CloundCompare在點、線、面三種模式下的顯示內容? 圖1&#xff1a;點模式? 圖2&#xff1a;線模式? 圖3&#xff1a;面模式 增加控制菜單欄實現測量功能類如何調用項目git鏈接 CloundCompare在點、線、面三種模式下的顯示內容 點 線 面 三張圖展示了 CloudComp…
閱讀更多...
4000萬日訂單背后，餓了么再掀即時零售的“效率革命”

4000萬日訂單背后，餓了么再掀即時零售的“效率革命”

當即時零售轉向價值深耕&#xff0c;贏面就是綜合實力的強弱。 文&#xff5c;郭夢儀 編&#xff5c;王一粟 在硝煙彌漫的外賣行業“三國殺”中&#xff0c;餓了么與淘寶閃購的日訂單量竟然突破了4000萬單。 而距淘寶閃購正式上線&#xff0c;還不到一個月。 在大額福利優惠…
閱讀更多...
vedio.ontimeupdate()和video.onloadeddata（）

vedio.ontimeupdate()和video.onloadeddata（）

video.onloadeddata &#xff08;&#xff09; video.onloadeddata 是 JavaScript 中用于監聽 HTML <video> 元素 「當前幀數據已加載」 的事件處理器。當視頻的第一幀畫面數據加載完成&#xff08;足以開始播放&#xff09;時&#xff0c;會觸發此事件。 1. 基本用法 …
閱讀更多...
Baklib內容中臺革新企業知識實踐

Baklib內容中臺革新企業知識實踐

Baklib智能知識中樞構建 作為現代企業知識管理的核心架構&#xff0c;Baklib內容中臺通過整合多源異構數據形成智能化知識中樞&#xff0c;實現從信息采集到價值轉化的全鏈路管理。其底層采用跨平臺數據貫通技術&#xff0c;支持API接口與企業現有CRM、ERP系統無縫對接&#x…
閱讀更多...
用不太嚴謹的文字介紹遙測自跟蹤天線的基本原理

用不太嚴謹的文字介紹遙測自跟蹤天線的基本原理

前兩天跟一個客戶見面的時候&#xff0c;客戶問我&#xff1a;遙測自跟蹤天線能夠跟蹤目標&#xff0c;是什么原理&#xff1f;不需要目標的位置&#xff0c;怎么做到自跟蹤的&#xff1f; 突然一瞬間&#xff0c;有點語塞。 難道要介紹天線、饋源、極化、左旋、右旋、和差網…
閱讀更多...
VS配置redis環境、redis簡單封裝

VS配置redis環境、redis簡單封裝

一、安裝redis數據庫 1.下載redis的壓縮包 wget https://download.redis.io/releases/redis-6.0.5.tar.g 2.解壓縮redis壓縮包&#xff0c;一般就在當前路徑 tar -zvxf redis-6.0.5.tar.gz -C /usr/local/redis 方便找我把它解壓縮在/usr/local/redis&#xff0c;如果沒有r…
閱讀更多...
C++23 已移除特性解析

C++23 已移除特性解析

文章目錄 引言C23 已移除特性介紹1. 垃圾收集的支持和基于可達性的泄漏檢測&#xff08;P2186R2&#xff09;背景與原理存在的問題移除的影響 2. 混合寬字符串字面量拼接非良構&#xff08;P2201R1&#xff09;寬字符串編碼概述混合拼接的問題示例分析移除的意義 3. 不可編碼寬…
閱讀更多...
Cloudflare

Cloudflare

Cloudflare 是一個網絡基礎設施和網站安全服務提供商&#xff0c;它的主要作用是讓網站 更快、更安全、更可靠。簡單來說&#xff0c;它是一個“護盾 加速器”。 &#x1f9e9; Cloudflare 的主要功能&#xff1a; 1. &#x1f680; 加速網站訪問&#xff08;CDN&#xff09…
閱讀更多...
Spring Boot啟動慢？Redis緩存擊穿？Kafka消費堆積？——Java后端常見問題排查實戰

Spring Boot啟動慢？Redis緩存擊穿？Kafka消費堆積？——Java后端常見問題排查實戰

Spring Boot啟動慢&#xff1f;Redis緩存擊穿&#xff1f;Kafka消費堆積&#xff1f;——Java后端常見問題排查實戰 引言 Java后端系統因其豐富的技術棧和復雜的業務邏輯&#xff0c;常常面臨啟動延遲、性能瓶頸、異常錯誤等多種挑戰。從核心語言、Web框架到分布式微服務及緩…
閱讀更多...
數字人引領政務新風尚：智能設備助力政務服務

數字人引領政務新風尚：智能設備助力政務服務

在信息技術飛速發展的今天&#xff0c;政府機構不斷探索提升服務效率和改善服務質量的新途徑。實時交互數字人在政務服務中的應用正成為一大亮點&#xff0c;通過將“數字公務員”植入各種橫屏智能設備中&#xff0c;為民眾辦理業務提供全程輔助。這種創新不僅優化了政務大廳的…
閱讀更多...
ToolsSet之：十六進制及二進制編輯運算工具

ToolsSet之：十六進制及二進制編輯運算工具

ToolsSet是微軟商店中的一款包含數十種實用工具數百種細分功能的工具集合應用&#xff0c;應用基本功能介紹可以查看以下文章&#xff1a; Windows應用ToolsSet介紹https://blog.csdn.net/BinField/article/details/145898264 ToolsSet中Number菜單下的Hex Operate工具可以進…
閱讀更多...
DSP處理數字信號做什么用的？

DSP處理數字信號做什么用的？

DSP&#xff08;數字信號處理器&#xff09;的核心任務是高效、實時地處理數字信號&#xff0c;通過專用硬件架構和算法優化&#xff0c;完成對信號的轉換、增強、分析和控制。以下是DSP處理數字信號的主要用途及典型場景&#xff1a; 1. 信號增強與優化 降噪&#xff08;Noise…
閱讀更多...
電腦如何保養才能用得更久

電腦如何保養才能用得更久

在這個數字化的時代&#xff0c;電腦已經成為了我們生活和工作中不可或缺的伙伴。無論是處理工作文檔、追劇娛樂&#xff0c;還是進行創意設計&#xff0c;電腦都發揮著至關重要的作用。那么&#xff0c;如何讓我們的電腦“健康長壽”&#xff0c;陪伴我們更久呢&#xff1f;今…
閱讀更多...
設計模式-監聽者模式

設計模式-監聽者模式

文章目錄 監聽者模式 監聽者模式 監聽器模式指的是事件源經過事件的封裝傳給監聽器&#xff0c;當事件源觸發事件之后&#xff0c;監聽器收到事件的通知并執行事件回調方法。 -監聽者觀察者概念定義當范圍對象的狀態發生變化時&#xff0c;服務器自動調用監聽器對象中的方法來…
閱讀更多...
小程序33-列表渲染

小程序33-列表渲染

列表渲染 就是指通過循環遍歷一個數組或對象&#xff0c;將其中的每個元素渲染到頁面上 在組件上使用 wx:for 屬性綁定一個數組或對象&#xff0c;既可使用每一項數據重復渲染當前組件 每一項的變量名默認為item&#xff0c;下標變量名默認為index 在使用 wx:for進行遍歷的時候…
閱讀更多...
[ Qt ] | QRadioButton和QCheckBox的使用

[ Qt ] | QRadioButton和QCheckBox的使用

目錄 QRadioButton 常用屬性 clicked(bool)信號、pressed信號、released信號 小項目 QRadioButton QRadioButton是一個單選按鈕&#xff0c;也是繼承自QAbstractButton(繼承自QWidget) 常用屬性 checkable 是否能選中 checked 是否已經被選中 autoExclusive 是否排…
閱讀更多...
最新文章

Copyright @ 2022~2023