###### tags: `GF Work`
# 20221014、20221020~20221024
## 10/14(五)
### 工作事項:
1.看完影片如何解Issue

*先打API看對應 controller，trace 程式首先去看用到哪些日誌及數據，再來去 Kibana 找相關資訊再做判斷，猜測問題發生原因，再回去找資料庫或是程式邏輯有哪邊出錯*

#
2.研究 jenkins 使用上板流程
*至 master 將最新版 pull 下來，新開 branch 做修改，之後推上 Test 做測試(Test 是 SIT環境，若 SIT 環境測試沒問題，再推上 master*

Nexus
遠端環境架設，把一些外部連結套件儲存至 Nexus，以免外部連結失效。

### 分享連結:
jenkins
https://tso-liang-wu.gitbook.io/learn-ansible-and-jenkins-in-30-days/jenkins/jenkins/jenkins-intro

## 10/20(四)
### 工作事項:
解ISSUE #103 注册人数错误

10/2 客戶列表正确注册人数为337 公司输赢报表的註冊人數為338

發現原因
有一筆資料在ES裡的 timestamp 顯示為
1664639999701 ID:253571
而DB裡面因為格式從timestamp轉為datetime
所以顯示為 2022-10-02 00:00:00

實際在kibana數據上查詢

timestamp between
1664640000000 - 1664726340000

只會有337筆數據

其中第一筆 ID:253571

而在DB裡，被歸在10-02號，才會造成數據上的誤差

#
因為輸贏報表的Data 是ORM 從 db 直接拉的



### 雷點:
GMT +8

### 分享連結:
mysql 自動四捨五入 (Docker compose - 5.7.32 ver.)
https://blog.csdn.net/dujianxiong/article/details/60571354

mysql 去除四捨五入(Java - 去除毫秒位)
https://blog.csdn.net/Lamborrt/article/details/105774250

timestamp 時間戳記轉換器
https://cloud.magiclen.org/tw/timestamp

## 10/21(五)
### 工作事項:

1.研究ISSUE #103
Think : 初步 3個idea

1. 改DB的TimeStamp 記錄方式 (改成紀錄timestamp) --- 對DB做更改，改動層面大
2. ES在拉DB資料時，不要將TimeStamp精確度至毫秒，用同樣的方式四捨五入 (X)
3. 改ES搜尋條件，將搜尋時間提早至前一晚的59:59:500以後 --- 對程式邏輯較為奇怪，需特別註解 (X)

### 疑點
待研究 等待TONY協助
-> 為什麼DB和ES的時間格式不一樣 ，DB 沒毫秒(date)，ES 卻是毫秒(timestamp)，而 ES 從 DB 拉資料時又是怎麼改的。

- try : 程式拿 timestamp

2.驗證 DB date - 發現確實DB沒存毫秒(不確定PROD環境是否也是)

select microsecond(register_date) from gl_user where register_date like '2022-10-02 %';

3.Tony 的 Github 教學

java LocalTime
https://docs.oracle.com/javase/8/docs/api/java/time/LocalTime.html

mysql 識別毫秒
https://blog.csdn.net/weixin_35545176/article/details/115882849?spm=1001.2101.3001.6650.6&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-6-115882849-blog-107877800.pc_relevant_recovery_v2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7ERate-6-115882849-blog-107877800.pc_relevant_recovery_v2&utm_relevant_index=8

## 10/24(一)
### 工作事項:

ISSUE #57
猜測是註冊當天換代理，導致當天的註冊數及存款人數可能被計算到兩次，而導致實時數據跟代理輸贏報表的數據核對不上。
1. 先查詢 kibana 發現原上層代理為 xxf123456
2. 從後台去找現代理與原代理，在 8/20 這天，兩者的註冊人數、存款人數跟會員
3. 發現原代理 xxf123456 註冊人數、存款人數為0
4. ES 跟報表拉下來的原代理，註冊人數皆為 0 ，判斷應該不是此原因造成，重新再找其他原因

跟營運拉取08-20當天的DB數據，來找0820這天是多哪一筆數據，
目前已確認不是換代理而重複數據(沒有兩筆同樣的重複數據)

DB與ES的差異為 - > 304725603sejiao 這筆 ID:204509


正常來說，ID是照著註冊時間給的，此用戶 304725603sejiao 於 10/05 被 lingfeng86 覆蓋。
(後來發現可能是看錯)

### 本周規劃
1.繼續解ISSUE，
2.兩天ISSUE(2/3)，一天API對應文件(1/3)