自我介紹

面試官您好，我叫王云虎，來自東南大學(xué)自動化學(xué)院，專業(yè)是電子信息，目前是二年級碩士研究生。在研究生期間，擔(dān)任學(xué)院研會外聯(lián)部部長，同時獲得2021年學(xué)校三好研究生等榮譽(yù)稱號。熱愛學(xué)習(xí)，研究生期間主要研究方向?yàn)橐恍┤斯ぶ悄芩惴ǚ矫?#xff0c;目前已經(jīng)發(fā)表一篇EI檢索會議論文和一篇被SCI期刊已經(jīng)錄用的論文，期間也做了一些實(shí)驗(yàn)室接的后端項(xiàng)目，同時自己也和同門一起做了一個小項(xiàng)目，想尋求一份Java后端開發(fā)工程師的職位。

威騰項(xiàng)目

項(xiàng)目介紹

威騰母線監(jiān)控系統(tǒng)是和物聯(lián)網(wǎng)相關(guān)的項(xiàng)目。現(xiàn)在傳統(tǒng)行業(yè)都想和互聯(lián)網(wǎng)結(jié)合，來提升自身的競爭力。這樣的項(xiàng)目一般都有一些終端設(shè)備會采集并上傳運(yùn)行狀況等信息，后臺讀取這些信息，進(jìn)行處理，比如過限預(yù)警等，然后存儲在數(shù)據(jù)庫中。后臺除了和設(shè)備交互之外，還需要向前端提供分類查詢之類的服務(wù)，前端將數(shù)據(jù)以圖表等方式展現(xiàn)出來。

在這個項(xiàng)目中。我的主要工作是對項(xiàng)目進(jìn)行完善，主要負(fù)責(zé)的是設(shè)備解析模塊，并且在這個過程中學(xué)習(xí)Web項(xiàng)目的組成部分和開發(fā)過程。我使用工廠和策略等設(shè)計(jì)模式重構(gòu)設(shè)計(jì)了設(shè)備消息解析模塊。在我們這個項(xiàng)目中目前大約有三種不同類型的采集器，或者說傳感器，采集的數(shù)據(jù)不太相同，有的是電力數(shù)據(jù)，比如電壓電流，有的是溫度。之前這三種類型的消息都在一個函數(shù)內(nèi)解析完成，用if-elif-else這樣的分支語句來寫的，造成整體代碼非常長，而且后續(xù)需要修改、添加功能時，都需要在大幾百行的代碼里來尋找，可讀性和可維護(hù)性都很差。因此考慮使用三個單獨(dú)的類實(shí)現(xiàn)消息解析功能。設(shè)備傳過來的每幀消息里都會帶有一個“類型”的字段，所以可以根據(jù)這一字段，通過工廠獲取相應(yīng)的消息解析類。而且，我希望“類型”到實(shí)際處理類的轉(zhuǎn)換是通過配置文件來配置，而不是硬編碼在工廠的代碼里，于是采用策略模式，后續(xù)如果要添加新的消息類別，只需要添加一個新的消息處理接口實(shí)現(xiàn)類，再在配置文件中添加一行映射關(guān)系，這樣只需要一個工廠通過消息的類型就可以獲得相應(yīng)的消息解析類，可以真正實(shí)現(xiàn)開閉原則。我對工廠的實(shí)現(xiàn)大致是，啟動時，工廠從配置文件中讀取這些對應(yīng)關(guān)系，通過全限定名獲取消息解析類的Class對象，然后通過Spring工廠上下文獲取指定類型的Bean對象，通過實(shí)現(xiàn)Aplicationaware接口，獲得Spring工廠上下文對象。（這里之所以沒有使用newInstance()方法創(chuàng)建實(shí)例的原因是，消息處理類的內(nèi)部除了要處理消息之外，還得做存儲，采集的數(shù)據(jù)不同，所以存儲肯定也是存到不同的表里嘛。所以消息解析類還需要依賴DAO等對象，如果用newInstance()手動創(chuàng)建出來，還得對每個字段進(jìn)行賦值，非常麻煩，而注入依賴這件事，Spring IoC容器最擅長了，所以我通過Spring來獲取這些已經(jīng)初始化完成的消息處理類。）獲取到這些類之后，存入HashMap，在運(yùn)行時可以快速獲取消息處理程序。此外，由于Spring工廠上下文的創(chuàng)建比較慢，所以我不能在類實(shí)例化的時候就做剛剛所說的的初始化操作，而需要將初始化操作延遲到第一次使用工廠時，為了避免多線程競爭初始化的問題，我還采用了雙重鎖定判斷實(shí)現(xiàn)了延遲初始化。

（我使用模板模式則是因?yàn)槌橄蟪隽藘蓚€變化的因素，一個是工廠生產(chǎn)的消息解析類的子包名可能會變化，一個是類型到消息解析類映射關(guān)系的獲取方式可能會變化。現(xiàn)在我是采用配置文件配置這種關(guān)系，也許某一天，我可能會采用數(shù)據(jù)庫來獲取這種關(guān)系，我先預(yù)留出了這個變化因素。）

因?yàn)樵O(shè)備上傳數(shù)據(jù)比較快，大概是5s一幀，而且同一時間會有多個設(shè)備上傳數(shù)據(jù)，考慮到項(xiàng)目上線時，可能會有上萬臺設(shè)備同時在線，數(shù)據(jù)庫寫入壓力過大，尤其是因?yàn)槲覀兪菃螜C(jī)部署，因此采用Redis緩存一分鐘內(nèi)設(shè)備的消息，后臺啟用一個定時任務(wù)把緩存寫入數(shù)據(jù)庫。

如何處理設(shè)備端高并發(fā)網(wǎng)絡(luò)讀寫問題？

由于我們做的是物聯(lián)網(wǎng)類型的項(xiàng)目，所以不可避免地要與設(shè)備之間建立網(wǎng)絡(luò)連接通信。甲方聲稱它們未來會有幾千上萬臺設(shè)備，所以對于這么多的并發(fā)連接，我們這種單機(jī)部署的方式可能難以承受。因此，我們采用了阿里云物聯(lián)網(wǎng)平臺提供的消息隊(duì)列中間件來解決這一問題。設(shè)備將消息推送到阿里云上，我們的后端從阿里云一次性拉多條數(shù)據(jù)下來處理，這樣，與設(shè)備端相連的高并發(fā)網(wǎng)絡(luò)讀寫、維護(hù)長連接（什么是長連接？與設(shè)備相連時，設(shè)備需要時刻注意自己的網(wǎng)絡(luò)狀態(tài)，斷線時需要重連）、TCP粘包等問題就被解決了（或者說問題由專門的高并發(fā)中間件解決了，尤其我們還是用了阿里云的物聯(lián)網(wǎng)服務(wù)，所以相比于我們單機(jī)部署所有應(yīng)用的情況，性能會更好），服務(wù)端只需要開少量的線程，處理并存取數(shù)據(jù)即可。

除了維持大量網(wǎng)絡(luò)連接的問題之外，還需要考慮合并插入的問題，也就是將高頻的設(shè)備數(shù)據(jù)插入進(jìn)行緩存，然后定時插入數(shù)據(jù)庫中

為何使用Redis？項(xiàng)目中怎么使用的Redis

一面時的說辭

因?yàn)樵O(shè)備上傳數(shù)據(jù)比較快，大概是5s一幀，而且同一時間會有多個設(shè)備上傳數(shù)據(jù)，考慮到項(xiàng)目上線時，可能會有上萬臺設(shè)備同時在線，數(shù)據(jù)庫寫入壓力過大，尤其是因?yàn)槲覀兪菃螜C(jī)部署，因此采用Redis緩存一分鐘內(nèi)設(shè)備的消息，后臺啟用一個定時任務(wù)把緩存寫入數(shù)據(jù)庫。這里存在一個問題，由于一次性插入一分鐘內(nèi)的所有數(shù)據(jù)，這樣會丟掉每一幀消息的時間戳，所以前端獲取數(shù)據(jù)時，還需要通過時間插值還原出原始數(shù)據(jù)的時間戳——因?yàn)橐环昼娨淮?#xff0c;所以取出時，看看一幀里能拆分出多少次數(shù)據(jù)，做個除法得出大致的時間間隔，計(jì)算出每個數(shù)據(jù)點(diǎn)大致的時間，然后再推給前端

面對大佬時的說辭

我們的項(xiàng)目中使用到了redis，一方面是用來緩存設(shè)備消息的，因?yàn)樵O(shè)備上傳數(shù)據(jù)比較快，大概是5s一幀，而且同一時間會有多個設(shè)備上傳數(shù)據(jù)，考慮到項(xiàng)目上線時，可能會有上萬臺設(shè)備同時在線，數(shù)據(jù)庫寫入壓力過大，尤其是因?yàn)槲覀兪菃螜C(jī)部署，因此采用Redis緩存一分鐘內(nèi)設(shè)備的消息，后臺啟用一個定時任務(wù)把緩存寫入數(shù)據(jù)庫；第二個地方使用了redis是在一個郵件報(bào)警功能中，因?yàn)猷]件發(fā)送相對來說比較慢，所以業(yè)務(wù)程序中將它放到了redis的一個列表鍵里，然后有一個報(bào)警推送業(yè)務(wù)不停地讀這個隊(duì)列，進(jìn)行郵件發(fā)送的功能。

那你們?yōu)楹尾皇褂胔ashmap？

隨著后續(xù)學(xué)習(xí)的深入，我也覺得，在當(dāng)前這種單機(jī)部署的環(huán)境下，似乎沒有必要使用redis，設(shè)備消息緩存可以使用hashmap來做，郵件發(fā)送功能可以使用線程池來做。 但是redis還有一些功能，是hashmap和線程池給不了的。比如說，持久化，比如說數(shù)據(jù)相對來說更加安全，假如應(yīng)用服務(wù)器程序死掉了，數(shù)據(jù)就全消失了，但是存在redis中呢，只要系統(tǒng)不宕機(jī)，數(shù)據(jù)就不會丟失，即使系統(tǒng)宕機(jī)，還能從持久化的數(shù)據(jù)庫中恢復(fù)一些數(shù)據(jù)。 不過我覺得這些功能應(yīng)該有本地緩存框架可以實(shí)現(xiàn)，我沒有深入地了解過，只是印象里有一些本地緩存框架可以實(shí)現(xiàn)這種k-v存儲，以及持久化的功能。

你覺得什么時候才有必要使用redis

我個人感覺，起碼要在分布式環(huán)境下，才有使用redis的必要，最起碼，redis不應(yīng)該和應(yīng)用服務(wù)器部署在一起吧？ redis自身是集中式分布式緩存，所以用于共享一些狀態(tài)，比如分布式session可以存在redis中，這樣用戶就不會因?yàn)檎埱蟊宦酚傻讲煌姆?wù)實(shí)例上就重新登陸了。

項(xiàng)目有哪些可以改進(jìn)的地方

最重要的就是，部署的時候是不是可以使用Docker，簡化環(huán)境的配置；實(shí)際上也沒有必要使用Redis，都是單機(jī)部署，用本地緩存就足夠了

困難

最困難的事情就是剛接手這個項(xiàng)目，就是我剛剛說負(fù)責(zé)重構(gòu)的那個的時候，一臉懵逼吧，代碼很亂，甚至還有bug，然后就是一點(diǎn)文檔都沒有。我連需求、功能都不知道是什么，反正就是很崩潰，不知道該從哪里下手。

這個困難其實(shí)也好解決，反正萬事開頭難嘛，開頭的一兩天，我基本上都比較暴躁，但是后來熟悉了整個系統(tǒng)的功能之后，就一點(diǎn)一點(diǎn)慢慢改。我找到了之前的負(fù)責(zé)人，問了問每個功能是怎么用的，然后一天補(bǔ)一點(diǎn)，就逐漸熟悉了。

在這個過程中，我又發(fā)現(xiàn)了一個bug，就是每次我啟動這個程序，我自己的本子跑起來風(fēng)扇嗚嗚轉(zhuǎn)，我當(dāng)時還到處去問，是不是springboot比較費(fèi)cpu資源啊？師弟也沒給我肯定的答案，就說可能吧，然后我就一直以為是個正常現(xiàn)象。直到后來，我閑來無事翻代碼加注釋的時候，終于找到了這個bug在哪里，原來是因?yàn)?#xff0c;我們需要實(shí)現(xiàn)一個郵件報(bào)警功能，如果傳感器采集到的數(shù)據(jù)超限了，那就給項(xiàng)目的負(fù)責(zé)人發(fā)送一封郵件。當(dāng)時也設(shè)計(jì)得挺好的，因?yàn)榘l(fā)郵件是耗時工作，就把任務(wù)放到了Redis的一個列表鍵里，開了一個線程，死循環(huán)地去讀Redis的這個列表鍵，當(dāng)然一般情況下是不會有郵件報(bào)警的，所以這個線程就相當(dāng)于在死循環(huán)。找到這個bug之后，我就做了修改，我想的辦法就是說，每次如果獲取結(jié)果是空的話，那就讓這個線程休眠1s，如果獲取有結(jié)果的話，那就死循環(huán)獲取，把消息都讀完。

現(xiàn)在再看這個事，感覺處理的很不好，應(yīng)該第一時間查看哪個進(jìn)程cpu的使用率是最高的，然后可以使用jdk自帶的java VisualVM查看具體的哪個線程使用率最高。

Linux系統(tǒng)中，先使用top指令找到占用CPU過高的進(jìn)程pid。

首先顯示線程列表,并按照CPU占用高的線程排序：

[root@localhost ~]# ps -mp 41673 -o THREAD,tid,time | sort -rn

將需要的線程TID轉(zhuǎn)換為16進(jìn)制格式

[root@localhost ~]# printf "%x\n" 41846 a376

最后使用jstack命令打印出該進(jìn)程下面的此線程的堆棧信息：

[root@localhost ~]# jstack 41673 |grep "a376" -A 30

現(xiàn)在再看這個事，其實(shí)我又覺得，根本用不到Redis，包括項(xiàng)目里的一些緩存，也完全沒必要用redis，都是單機(jī)部署，直接在java內(nèi)部緩存一下不就好了嗎？對于發(fā)郵件這件事，我覺得，用線程池實(shí)現(xiàn)不就好了嗎？因?yàn)榫€程池是支持阻塞獲取的，甚至都不用考慮讓cpu暫停一會兒這樣的事了。

其實(shí)這個項(xiàng)目也還有挺多地方可以繼續(xù)整改的，因?yàn)檫@個學(xué)期我們的重心主要會放在找工作上面嘛，所以我都把它留給了師弟，并且把我認(rèn)為更好的設(shè)計(jì)，寫在了文檔里。雖然說也有點(diǎn)像是留了一堆鍋給師弟，但是起碼我沒有留bug給師弟，我留的是對這個項(xiàng)目的思考，更好的設(shè)計(jì)給他吧，而且還是有文檔的系統(tǒng)。我覺得這個項(xiàng)目現(xiàn)在最大的不足，就在于部署非常麻煩，需要裝一堆東西，什么mysql啊，redis啊，mysql的導(dǎo)出表啊，redis的rdb啊，項(xiàng)目里的靜態(tài)資源文件啊，我發(fā)現(xiàn)漏了一個文件就傳一個，傳得都不好意思了，所以我把使用Docker部署項(xiàng)目，放在了寫給師弟的建議里的第一行。

問題

消息隊(duì)列用來流量削峰？

redis內(nèi)部數(shù)據(jù)結(jié)構(gòu)，哈希鍵，每個項(xiàng)目內(nèi)部有一個哈希鍵用于存儲緩存的數(shù)據(jù)，哈希鍵內(nèi)部的鍵是采集點(diǎn)的編號，名是拼接的字符串?dāng)?shù)組。

SSD和機(jī)械硬盤的區(qū)別？

能不能畫個圖跟我說說，你們項(xiàng)目，redis，消息隊(duì)列之間的關(guān)系？

你們項(xiàng)目中有沒有考慮到可靠性？為什么需要Redis做合并寫入

實(shí)驗(yàn)室工具箱項(xiàng)目

為什么要設(shè)計(jì)實(shí)驗(yàn)室工具箱？

因?yàn)槲覍?shí)驗(yàn)室同門有一部分是做地震數(shù)據(jù)分析的，地震的一些數(shù)據(jù)需要使用爬蟲獲得，每次需要這些地震數(shù)據(jù)的時候其他人都會找我一個同門讓他幫忙爬一下，這樣每次都讓他有點(diǎn)煩。所以我們就想到建一個web，然后可以遠(yuǎn)程調(diào)用這些使用Python寫的各種數(shù)據(jù)獲取，數(shù)據(jù)處理的代碼，之后還方便對這個系統(tǒng)進(jìn)行擴(kuò)展，增添一些其他的功能。

為什么要使用單點(diǎn)登錄？

因?yàn)槲覀冇袛?shù)據(jù)獲取、數(shù)據(jù)處理等這些不同的模塊，如果不使用單點(diǎn)登錄，每次使用一個模塊都要進(jìn)行一次登錄驗(yàn)證。使用單點(diǎn)登錄就可以把登錄模塊單獨(dú)拿出來，用戶登錄成功后將用戶的登錄信息永JWT生成token存在redis里面,并設(shè)置一個過期時間，然后后面前端如果有需要登錄驗(yàn)證的需求的請求時，就可以使用一個攔截器將token取出來，查看redis里面有沒有當(dāng)前用戶的登錄信息。

為什么要使用JWT生成token？

因?yàn)槭褂肑WT更加安全，JWT由3部分組成：Header、有效載荷(Payload)和簽名，Header是一個JSON對象里面包含簽名所使用的算法，默認(rèn)為HS256，生成的令牌屬性。Payload也是一個JSON對象，是主體部分，我在里面存放的userid,username和時間戳。Head和Payload使用base64進(jìn)行編碼，簽名部分對使用base64編碼后的head和payload部分使用指定的算法進(jìn)行加密，并且加上一個密鑰，該密鑰只存在服務(wù)器中。驗(yàn)證登錄的時候首先判斷傳過來的token中的head和payload部分有沒有被篡改，然后再根據(jù)userid查詢用戶在不在redis里面。

為什么要使用springcloud？

因?yàn)橹耙蚕脒^就使用socket進(jìn)行連接，但是后面發(fā)現(xiàn)服務(wù)接口越來越多，就想使用一個框架對這些服務(wù)接口進(jìn)行統(tǒng)一管理。而且我也想以后對這個實(shí)驗(yàn)室工具箱進(jìn)行拓展，加一個留言板等功能，大家可以自由的在上面討論問題。

怎么使用springcloud的？

主要使用了springcloud的eureke服務(wù)注冊中心，專門負(fù)責(zé)服務(wù)的注冊和發(fā)現(xiàn)，里面有一個注冊表，保存了各個服務(wù)在哪臺機(jī)器上，端口號是多少，有了服務(wù)注冊與發(fā)現(xiàn)，只需要使用服務(wù)的標(biāo)識符，就可以訪問到服務(wù)。EureKa自我保護(hù)機(jī)制：默認(rèn)情況下，當(dāng)eureka server在一定時間內(nèi)沒有收到實(shí)例的心跳，便會把該實(shí)例從注冊表中刪除（默認(rèn)是90秒），但是，如果短時間內(nèi)丟失大量的實(shí)例心跳，便會觸發(fā)eureka server的自我保護(hù)機(jī)制，該保護(hù)機(jī)制的目的是避免網(wǎng)絡(luò)連接故障，在發(fā)生網(wǎng)絡(luò)故障時，微服務(wù)和注冊中心之間無法正常通信，但服務(wù)本身是健康的，不應(yīng)該注銷該服務(wù)，如果eureka因網(wǎng)絡(luò)故障而把微服務(wù)誤刪了，那即使網(wǎng)絡(luò)恢復(fù)了，該微服務(wù)也不會重新注冊到eureka server了，因?yàn)橹挥性谖⒎?wù)啟動的時候才會發(fā)起注冊請求。

AP可用性和一致性

Feign:實(shí)現(xiàn)服務(wù)調(diào)用的，只需要創(chuàng)建一個接口并使用注解的方式來配置它，即可完成對服務(wù)提供方的接口綁定，讓微服務(wù)之間的調(diào)用變得更簡單，類似controller調(diào)用service.（Feign Client會在底層根據(jù)你的注解，跟你指定的服務(wù)建立連接、構(gòu)造請求、發(fā)起靕求、獲取響應(yīng)、解析響應(yīng)，等等。）如果你對某個接口定義了@FeignClient注解，Feign就會針對這個接口創(chuàng)建一個動態(tài)代理接著你要是調(diào)用那個接口，本質(zhì)就是會調(diào)用 Feign創(chuàng)建的動態(tài)代理， Feign的動態(tài)代理會根據(jù)你在接口上的注解，來動態(tài)構(gòu)造出你要請求的服務(wù)的地址，最后針對這個地址，發(fā)起請求、解析響應(yīng)

Hystrix實(shí)現(xiàn)服務(wù)降級，當(dāng)獲取數(shù)據(jù)的時候，如果請求獲取10年地震tec的數(shù)據(jù)，由于地震數(shù)據(jù)很龐大，使用爬蟲在網(wǎng)上獲取的，如果要獲取十年的數(shù)據(jù)很可能出現(xiàn)內(nèi)存不夠的問題，所以就想到使用hystrix服務(wù)降級。使用hystrix的超時時間，如果時間超過60秒，就發(fā)生服務(wù)降級，返回null，并且通知發(fā)生服務(wù)降級，請適當(dāng)縮小日期間隔，每次請求最好保證時間在60天內(nèi)。

算法項(xiàng)目

項(xiàng)目背景：能源在人類發(fā)展史上扮演著極其重要的作用，但是目前能源緊缺與環(huán)境污染問題日漸突出，人們開始對太陽能、風(fēng)能等可再生清潔綠色能源的利用方式進(jìn)行研究。目前，城市智慧能源系統(tǒng)建設(shè)尚處于探索階段，對其進(jìn)行研究，可以優(yōu)化城市能源結(jié)構(gòu)、提高能源利用效率、促進(jìn)清潔能源開發(fā)利用，最終實(shí)現(xiàn)城市能源消費(fèi)的低碳化。

首先從城市功能出發(fā)，調(diào)研各參與方的需求，總結(jié)出城市智慧能源的定義。然后對系統(tǒng)的信息物理系統(tǒng)進(jìn)行研究，基于信息物理系統(tǒng)構(gòu)建系統(tǒng)的信息物理架構(gòu)。接著對系統(tǒng)的功能架構(gòu)進(jìn)行研究，系統(tǒng)架構(gòu)由形式與功能的映射構(gòu)成，其中，形式是指系統(tǒng)的物理體現(xiàn)與信息體現(xiàn)，功能通過形式來執(zhí)行，形式對功能起著工具性的作用。因?yàn)槿魏问挛锏陌l(fā)展總是需要評價(jià)評估，因此對系統(tǒng)進(jìn)行評價(jià)是很有必要的，所以最后建立城市智慧能源系統(tǒng)的綜合評價(jià)體系。在這個項(xiàng)目中，我主要的工作是對城市智慧能源系統(tǒng)功能架構(gòu)的應(yīng)用微電網(wǎng)配置優(yōu)化進(jìn)行研究，和建立城市智慧能源系統(tǒng)的綜合評價(jià)體系。

物理架構(gòu)：通過對城市智慧能源系統(tǒng)各方需求進(jìn)行分析，搭建以電熱冷氣交通為主要能源輸入，建立和可再生能源天陽能、風(fēng)能等進(jìn)行多能互補(bǔ)為重要物理特征的物理架構(gòu)。在CPS中，信息網(wǎng)絡(luò)深深地嵌入在每個物理部件上，每個物理部件在覆蓋于其上的信息空間的作用下能夠?qū)崟r地自我控制，同時，不同物理部件還可以在信息網(wǎng)絡(luò)的幫助下靈活通信。分為智能終端設(shè)備，能源管理站，能源智慧服務(wù)平臺。

功能架構(gòu)：能源系統(tǒng)安全、能源協(xié)同控制、能源數(shù)據(jù)服務(wù)與能源交易市場。化石能源的枯竭和環(huán)保的訴求，使得綠色能源成為大家關(guān)注的話題，但是傳統(tǒng)電網(wǎng)對消納綠色能源顯得十分吃力，微電網(wǎng)被認(rèn)為是緩解上述問題的一個解決方法。微電網(wǎng)協(xié)同優(yōu)化屬于能源協(xié)同控制模塊，微電網(wǎng)配置優(yōu)化是微電網(wǎng)協(xié)同優(yōu)化運(yùn)行的一個子問題，它屬于數(shù)據(jù)服務(wù)模塊的內(nèi)容，微電網(wǎng)適當(dāng)?shù)呐渲酶欣谖㈦娋W(wǎng)協(xié)同優(yōu)化運(yùn)行。

微電網(wǎng)配置優(yōu)化主要是配置小型園區(qū)風(fēng)力發(fā)電機(jī)、光伏發(fā)電機(jī)、柴油發(fā)電機(jī)和儲能設(shè)備的數(shù)量，目標(biāo)函數(shù)為初始裝機(jī)成本、運(yùn)行成本、維護(hù)成本、治理成本組成，有四個目標(biāo)函數(shù)，同時考慮經(jīng)濟(jì)性環(huán)保型等問題，是一個多目標(biāo)優(yōu)化問題。首先通過遺傳算法求出Pareto最優(yōu)解集，然后將Pareto最優(yōu)解集作為PCA的樣本數(shù)據(jù)，通過主成分分析法求出第一主成分的向量，然后確定各個目標(biāo)函數(shù)的權(quán)重，將其轉(zhuǎn)化為單目標(biāo)優(yōu)化問題，然后在使用遺傳算法求解單目標(biāo)優(yōu)化問題。

問題：在仿真實(shí)驗(yàn)的時候發(fā)現(xiàn)每次求出來的各個目標(biāo)函數(shù)的權(quán)重都有一些細(xì)微差別，原因是，再多目標(biāo)問題中，使用遺傳算法求出來對Pareto最優(yōu)解具有一定的隨機(jī)性。解決方案：多做幾次實(shí)驗(yàn)，然后再求平均值求出各個目標(biāo)函數(shù)的權(quán)重。

對一個系統(tǒng)進(jìn)行評價(jià)首先要建立系統(tǒng)的評價(jià)指標(biāo)體系。通過對城市智慧能源系統(tǒng)需求進(jìn)行分析，最后從高效性、經(jīng)濟(jì)性、可靠性、社會性、互動性五個方面選取評價(jià)指標(biāo)，建立系統(tǒng)的評價(jià)指標(biāo)體系。并將城市智慧能源系統(tǒng)分成四個級別，然后將這些評價(jià)指標(biāo)作為神經(jīng)網(wǎng)絡(luò)的輸入，輸出為系統(tǒng)的級別。因?yàn)槌鞘兄腔勰茉聪到y(tǒng)剛剛處于起步發(fā)展階段，數(shù)據(jù)集較少，而訓(xùn)練神經(jīng)網(wǎng)絡(luò)需要大量的數(shù)據(jù)集，因此使用SeqGAN對數(shù)據(jù)集進(jìn)行擴(kuò)充.因?yàn)樯窠?jīng)網(wǎng)絡(luò)權(quán)值和閾值的初始值會對網(wǎng)絡(luò)模型訓(xùn)練產(chǎn)生影響，容易造成陷入局部最優(yōu)問題，因此使用遺傳算法優(yōu)化神經(jīng)網(wǎng)絡(luò)權(quán)值和閾值的初始值。

問題：數(shù)據(jù)集獲取較困難，評價(jià)指標(biāo)是自己建立的，很難獲得完整的數(shù)據(jù)集，而且城市智慧能源系統(tǒng)剛剛處于起步發(fā)展階段，數(shù)據(jù)集獲取更加困難。

解決：項(xiàng)目是和電科院合作的，電科院陸續(xù)提供了一部分未處理的數(shù)據(jù)，然后再通過調(diào)研互聯(lián)網(wǎng)收集等將這些數(shù)據(jù)轉(zhuǎn)變?yōu)榻⒌脑u價(jià)指標(biāo)的數(shù)據(jù)，最后數(shù)據(jù)量還是有點(diǎn)不足，然后通過SeqGAN生成對抗網(wǎng)絡(luò)來擴(kuò)充數(shù)據(jù)集。

城市智慧能源系統(tǒng)是以城市為運(yùn)行范圍，結(jié)合材料、環(huán)境工程、電力電子、通信、人工智能等學(xué)科理論，合理應(yīng)用信息通信技術(shù)和先進(jìn)控制技術(shù)，向信息化、網(wǎng)絡(luò)化、智能化、平臺化轉(zhuǎn)型，充分利用多能互補(bǔ)和源網(wǎng)荷儲協(xié)同優(yōu)化，提升系統(tǒng)穩(wěn)定性、安全性、經(jīng)濟(jì)性、高效性與環(huán)保性，提升城市能源服務(wù)質(zhì)量

總結(jié)

以上是生活随笔為你收集整理的面试项目介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。