2017年7月25日---階段性工作總結

通過本階段工作,總結如下:

通過需求學習,熟悉了springboot基本使用,熟悉了springcloud各組件的功能。

持久層框架原本是spring data jpa 但是實在用不習慣,因此改爲了mybatis,+springMVC

測試使用了postman。

創建,更新和鏈接第三方數據庫實現起來非常簡單,不多說。

查詢數據庫中表的功能。由於數據庫類型不同,因此採用了DatabaseFactory(工廠模式)根據傳入的數據庫類型,switch....case....返回DatabaseServiceImpl實例。再通過這個實例得到數據庫鏈接對象Connection。


根據用戶選擇的列返回數據,接收json格式的list對象,通過遍歷,使用StringBuffer的append動態拼接查詢參數。使用connection對象查詢。


本項目還使用到了構造者設計模式,會在之後的博客中詳細說明。



2017年7月26日(內蒙古移動渠道管理系統,去除hibernate二級緩存,改爲redis用作二級緩存)

組長讓我對一個原有項目進行改造。我在自己的電腦上部署完項目以後,開始是bean注入的問題,找不到指定的類。經過查看發現啓動項目的target中沒有需要的一個class文件,我將被依賴的那個模塊的輸入目錄改爲與調用者(這裏也就是啓動項目的target目錄一直)解決了該問題。

第二個問題。耽誤了我很長時間。原因是我本機用的是jdk8,因爲考慮到8有很多新特性。但是我忽略了8只支持spring4以上。我又重新下載的jdk7.重新編譯運行即可。

該項目web模塊是maven工程,其他被依賴的模塊都是普通的那種工程。在本地部署時如何添加依賴等,也讓我重新回顧了一下。

今天我在完成redis替代hibernate作爲二級緩存的時候,突然想到一個問題。hibernate的二級緩存是默認的,可以緩存所有查詢。但是redis是自己控制的。有默認的不用幹嘛非得要用自己控制的。百思不得其解,於是問了一下高手,得到回答如下:

hibernate的二級緩存默認是ehcache,本質是應用緩存,應用緩存當然也有用武之地。我個人理解,一般情況下關掉二級緩存的原因是,跨請求的cache共享很複雜,

而且會和自身的業務有關係,而持久化的二級緩存操作對程序員是黑盒的,這樣可能會造成一些風險,所以我們一般禁用掉二級緩存,而結合業務的特點來自己做跨鏈接

的緩存操作,這些操作是程序員可控的


由於在本次工作中,我將hibernate的二級緩存關了,然後使用redis手動去控制緩存。但是肯定不如hibernate的全面,然後組長說(我理解)spring可以整合二級緩存,

只要有增刪改查都去處理緩存。因此我需要跟進。因爲我的方式對原有代碼的侵入性太強了。

ehcache直接在jvm虛擬機中緩存,速度快,效率高;但是緩存共享麻煩,集羣分佈式應用不方便。
redis是通過socket訪問到緩存服務,效率比ecache低,比數據庫要快很多,處理集羣和分佈式緩存方便,有成熟的方案。

如果是單個應用或者對緩存訪問要求很高的應用,用ehcache。
如果是大型系統,存在緩存共享、分佈式部署、緩存內容很大的,建議用redis。

補充下:ehcache也有緩存共享方案,不過是通過RMI或者Jgroup多播方式進行廣播緩存通知更新,緩存共享複雜,維護不方便;
簡單的共享可以,但是涉及到緩存恢復,大數據緩存,則不合適。


sql優化,當父節點下子節點特別多的時候,逐個發送sql語句根據父節點逐個查詢的效率就不如查詢整張表效率高了。

in查詢條件在mysql5.7以後支持索引了


今天無意中看到一篇事務相關的文章有一句話非常經典

 spring的事務是通過spring的動態代理實現的,
但是如果在對象內部的方法使用this調用其他的函數,
那這個this就是對象本身,而不是spring容器中的代理,所以就喪失了事務的能力 






發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章