原创 對項目工作的一點思考

1,當系統出現性能問題的時候,優化的時候一定要考慮全面,不能現在這個功能優化好了,其他地方又出現新的問題(生產環境有時候不太好做性能測試,主要是生產環境的機器測試環境肯定是沒有辦法模擬的,但是自己需要想辦法模擬一個類似的場景來進行驗證測試

原创 數據庫大表超大表遷移歸檔方案(以oracle爲例子)

原理:超大數量表的情況下,採用將原來表作爲歸檔表,而不是直接複製原始表到歸檔表,如果需要保留一部分數據,再從歸檔表中遷移一部分數據原始表 T_IM_MESSAGE 原始表 T_IM_MESSAGE_LOG 歸檔表 第一步,複製新建立一個與

原创 2019年小總結

1,年初時結了婚,運氣很好是高三時期喜歡的女孩子 2,家人被電話詐騙  12W多(大半年過去都未破案,估計是破不了案了),這一關我們挺過去了 3,去年買的房12.31如期交了房,小區的環境很好 4,年底的時候被評了優秀員工,還加了工資,今

原创 (生產事故)openfire內存只增不減,也一直不GC

我們有一個老項目是基於openfire開發的客服以及消息推送,用戶總量在300W左右,高峯期同時在線是5W人左右   第一次運維反饋openfire使用內存比例佔用一直在50%以上,居高不下 因爲是老項目,也沒有特別重視(1,老項目,2,

原创 (生產事故)表不設計索引導致數據庫大量查詢超時,機器cpu100%,app不能正常使用

16年得時候我們上線了一個統計消息推送消息到達率的功能 我們消息分爲在線消息(openfire)離線消息 蘋果apns推送 在線消息:用戶手機收到推送消息以後,返回一個回執業務號到後臺 離線消息:消息調用apsn接口蘋果會返回一個成功狀態

原创 (生產事故)rabitmq大量隊列數量有增無減,消費組件又一直在打消費日誌,進而影響app整體功能

2015年的一天,早上突然很多用戶反饋消息系統出現空白且在使用功能的使用與有提示系統異常 嚇得我馬上上生產機器看日誌,發現大量接口調用超時,且mq消費日誌不停的再打,很瘋狂那種 我們想到的是昨天是正常的,爲什麼突然之間就大量報錯呢,並看錯

原创 引入外部框架JS出現亂碼問題解決

有時敲代碼很容易忘掉一下細節問題 再引入js的時候,有時覺得便利通常不會考慮其他可能會直接引入,這一點如果是自己編寫的代碼可能不會出現亂碼的情況,但是引用外部框架的時候,就極大的機率出現亂碼問題 亂碼問題前  JS  引入方式    <

原创 oracle與mysql數據庫基本數據類型--介紹與區別

再這裏我寫的時我們常常用到的,不會每個類型都介紹到 一,mysql 字符串類型、數字類型、日期類型 //LOB類型、LONG RAW& RAW類型、ROWID & UROWID類型。 mysql   數據

原创 前端數據接口被惡意調用 兩個例子

一,微信贈送流量活動   五萬塊一上午就滅了 去年再微信公衆號上搞了一個有獎問卷調查答題,主要是贈送流量 分爲 大於九十分 100m流量  及格60分 50m流量  未及格者獲得30m流量  這個流量套餐根據移動,聯通,電信贈送的還不一樣

原创 plsql左側窗口列表講解

這些列表內容,新人甚至寫代碼寫了幾年的,也不能全部每個功能的大致作用,今天我整理一遍,給大家講解一遍 1,recent objects 你最近訪問或是使用過的對象。 就是一個記錄,相當於的最近訪問的內容列表。 2,recycl