原创 設計模式之美學習-一些反思

業務場景,通過redis來模擬延遲消息處理 還是採用傳統思維模式 寫入消息 // 離線列表 延遲一分鐘 redisOperationService.zaddWithPrefix(BusinessRedisKeyD

原创 設計思路-消息推送防止大量推送

比如用戶離線,A用戶給B用戶連續發送消息,不要設計成發送一條就推一條 可以設置一個緩衝區,一定時間內都寫入緩衝區比如10秒內。10秒內發送5條消息 推送消息爲您有x條通知消息,點擊查看這種形式

原创 Gitlab-CICD

CICD是什麼 我們的開發模式經歷瞭如下的轉變:瀑布模型->敏捷開發→DevOps(Development、Operations的組合詞,是一組過程、方法與系統的統稱) 後來隨着DevOps的興起,出現了持續集成(Continuous In

原创 docker-dockerfile(五)

1

原创 k8s-故障排查

容器未啓動 1.先看deploy kubectl get deploy #查看deploy列表 kubectl describe deploy {depoloyname} #查看描述 2.如果描述看不出來則看pod kubectl g

原创 k8s-資源存儲

ConfigMap 基於命令創建 創建一個名爲my-config的configMap,並將key1和key2的值分別設置爲value1和value2。 kubectl create configmap my-config --from-l

原创 java陷阱之發版行爲準則

1.發版後對比發版後和發版前的日誌數據量 然後看差異 2.發版後關注error日誌 對比日誌數據量 3.發版後關注服務器內存cpu,負載 請求量,ingress有沒有明顯差異 4.發版後關注數據庫數據是否符合預期

原创 k8s-ingress

ingress的作用 再k8s裏面充當了nginx的作用 ingress是一種抽象 而不是具體實現,具體實現再控制器 安裝ingress控制器  

原创 k8s-service

說明 服務內部的訪問 service如何訪問到pod 1.訪問到service(創建service如果指定了selector會自動創建對應的endpoint) 2.找到對應的endpoint 3.通過iptables找到路由到對應節點的ku

原创 golang-引用傳遞

dbTags := make([]*Tag, 0) for _, value := range idMap { dbTags = append(dbTags, &value)

原创 設計思路-消費MQ

消費端收到消息 持久化到redis或者數據庫,狀態爲待處理。然後ack確認 再處理通過線程池異步消費消息,提高吞吐量(但是需要考慮應用線程異步有序性的問題  如線程池裏面加鎖保證原子性) 1.如redis 先通過zset放入redis  

原创 k8s-資源調度

滾動更新 注:是滾動更新 不是擴容 只有修改了deployment配置文件中的template中的屬性後,纔會分觸發更新操作如使用 kubctl edit deploy {name} 查看滾動更新情況 1.查看狀態 kubectl roll

原创 redis-redissearch臨時筆記

官方文檔 https://redis.io/docs/interact/search-and-query/ 底層數據結構支持 HASH FT.CREATE books-idx ON HASH PREFIX 1 book

原创 java陷阱之關於數據同步

需求 需要查詢設備列表。使用redissearch,需要從cannal->kafka->redis 問題 保證數據有序性和一致性(運維那邊不能根據設備id進行分區,到時消息消費時面臨消費的有序性問題)採用的是不使用binlog日誌修改信息,

原创 k8s-label和selector

說明 k8s通過lable來爲資源打上標籤,通過selector來查找。而不是像傳統mysql對象之間關聯使用強關聯外鍵屬性 比如deployment需要關聯RS 則通過RS打上標籤,deployment通過配置select選擇器去查找