網頁開發知識 | Web-Dev Blog
Intro Character Set: 字符集合，定義資料如何儲存與表示。 MySQL 支援多種字符集，例如： latin1, utf8mb4 Collation: 基於字符集，定義了字符集中的字符如何進行排序和比較。 MySQL 的 Collation 一般以以下格式命名，舉 utf8mb4_general_ci 為例： utf8mb4: 字符集名稱 general: 簡化的排序規則 (unicode為精準 Unicode 排序規則) ci(case insensitive): 大小寫不敏感 MySQL 字符集上在 8.4 版本後已經清楚且標準很多 MySQL 8.4 Reference Manual :: 12.2 Character Sets and Collations […]
Intro 在交易的應用場景下，可能需求為透過資料庫符合 ACID 快速產生唯一的交易編號作為 Primary key 或是 Unique key。 MySQL 實作 假設定義一組16碼的交易編號，格式為YYYYMMDD(8) + 流水號(8)。 這前提下代表一天內不建立超過8位數的 record，就可以利用 MySQL auto_increment 搭配 last_insert_id() 來實現： START TRANSACTION; INSERT INTO transactions (transaction_date, amount) VALUES (NOW(), 100); SET @last_id = LAST_INSERT_ID(); SET @fixed_length = 8; SET […]
Intro MongoDB Manual – Query Documents Mongo Shell The mongo Shell – MongoDB Manual 安裝 Mac $ brew tap mongodb/brew $ brew install mongodb-community-shell mongodb – Install mongo shell in mac – Stack Overflow Compass. The GUI for MongoDB. (TBC) […]
Intro 設計要點 即時搶票模型 若為 User base，則驗證資格後可以先把 status row lock，以免同一 user 搶超過數量限制 實際搶 ticket 則使用高效能的 ACID 資料結構實現即可 (例如 Redis DECR) 排隊消化模型 搶票即產生MQ，consume處理後更新狀態以供使用者後續查詢與繼續往下進行
Intro MongoDB – Wikipedia Introduction to MongoDB Cluster MongoDB Clusters Sharding MongoDB Sharding 分散式儲存架構建置 (概念篇) MongoDB Sharding 分散式儲存架構建置 (實作篇) Replica MongoDB Replica Set 高可用性架構搭建 Query / Mongo Shell [Mongo] Query & Mongo Shell 指南
Intro Concurrency control – 並行控制 分類上目前可分為三種： 樂觀鎖（Optimistic Locking） 悲觀鎖（Pessimistic Locking） 半樂觀鎖 (Semi-optimistic Locking) * Database – 資料庫管理系統 樂觀鎖 – OCC 樂觀並行控制 – Optimistic Concurrency Control，縮寫「OCC」 不利用內建鎖機制，而是利用應用層邏輯解決衝突 可透過讀取資料時分派一個版本或時間戳，通過校驗後寫入否則中斷(實作上可利用寫入連帶驗證版本達成) 適合交易之間資料競爭(data race)概率較小的應用情境 MySQL 實現範例 update DB.table set quantity = quantity -1 , version […]
Intro Elasticsearch 是與名為 Logstash 的資料收集和紀錄檔解析引擎以及名為 Kibana 的分析和視覺化平台一起開發。這三個產品被設計成一個整合解決方案，稱為「Elastic Stack」（以前稱為「ELK stack」）。 Wiki – Elasticsearch ELK Stack: Elasticsearch, Logstash, Kibana | Elastic OpenSearch OpenSearch 包含了搜尋引擎與 OpenSearch Dashboards（此搜尋引擎的資料可視化儀錶板）。此軟體始於2021年，作為 Elasticsearch 與 Kibana 的分支，主要由AWS(亞馬遜雲端運算服務)開發。(Wikipedia) OpenSearch Github: OpenSearch Project opensearch-project/OpenSearch: 🔎 Open source distributed and RESTful search […]
Intro 防範XSS、SQL Injection以及驗證資料已經是基本開發流程，但要如何標準化的去做團隊開發就是一門學問。 資料驗證 顧名思義，就是在寫入Datebase之前處理Input資料驗證。 以MVC架構來說，Validator最佳的實踐流程點是在Model/Entity上，也就是Model已定義好驗證規則，所以所有經過此Model寫入的資料都會是經過經過規則驗證通過的，提供絕佳的共用性與嚴謹度。 Yii 2 – Validating Input (Yii 2 透過Model定義Validator實踐開發) CodeIgniter/Model – Validation (CI擴充框架中，一樣透過Model定義整合Validator實踐開發) Filter前處理or後處理 以XSS來說，到底要前處理還是後處理? 兩個都沒錯，這全看你後端/資料庫那個欄位到底是定義成Plain Text還是HTML Content。 平均開發上，只要一開始寫資料庫沒特別定義，不外乎都是Plain Text，意即做後處理比較直覺(畢竟過往資料都寫進去了)。 後處理缺點 每次在前端(HTML)顯示時都須謹記後處理，漏一個沒處理就中了廣義XSS 前處理缺點 因為資料預設就是HTML，所以應付前端不須處理；相反的在需要Plain Text(例如Excel Plain Text)時就需要在後處理反轉回來 無法保障資料驗證，因為輸入過濾將影響驗證一致性，例如最大字數通過過濾的不確定性造成不精準 遇到textarea給值時需要Decode回來 (歸類input，正規給值方式value或jQuery val()，用html不標準) 綜合以上，優缺點是一體兩面的，取決於需求。 例如80/20法則，前端顯示開發較多、Plain Text顯示開發較少，那選前處理絕對較省成本，且較嚴謹(畢竟反轉與否不影響安全性)，所以依照專案與團隊自行評估即可。 我個人對於Pattern來說會選擇後處理為主，因為儲存資料定義為原始輸入資料(Plain […]
Intro 一個專案會有遇到需要操作多個資料庫的情境，然而多資料庫分離的Type一般分兩類： 同一Application分主資料庫和附屬資料庫，如分myapp與myapp_log兩個DB。 異質系統，若非API串接，也是有可能直接SQL Connection跨過去連線異質資料庫。 異質系統資料庫連線 異質系統連線沒甚麼設計模式，基本上必定需要另外設定一個連線，以PHP Yii2 Framework連線異質MySQL為例： return [ ‘components’ => [ ‘db’ => [ ‘class’ => ‘yii\db\Connection’, ‘dsn’ => ‘mysql:host=localhost;dbname=myapp’, ‘username’ => ‘user’, ‘password’ => ‘pass’, ‘charset’ => ‘utf8’, ], ‘dbOtherApp’ => [ ‘class’ => ‘yii\db\Connection’, ‘dsn’ […]
Intro Redis 快速安裝檔 安裝 $ sudo apt install redis-server That’s all 進階設定 開啟驗證 新增密碼設定 /etc/redis/redis.conf: requirepass your-password-here Redis驗證僅使用密碼，不需要帳號 Bind IP驗證 /etc/redis.conf: bind 192.168.1.100 10.0.0.1 不支援子網遮罩，不需要就註解掉，自行設防火牆。 管理介面套件 phpRedisAdmin Additoins TTL (Time to live) Redis – TTL key EXPIRE key seconds [ […]