高級工程師筆試題

一、什麼是js跨域問題？說出3種js跨域解決方案
二、數據庫設計、優化心得
三、什麼是值類型、引用類型？關鍵詞：內存分配、賦值、參數傳遞（out、ref）、釋放
四、介紹微服務，以及網關、服務註冊、熔斷降級
五、介紹.Net Core的中間件
六、介紹OAuth2.0、JWT
七、什麼是MQ、你用過那些MQ，什麼場景下使用？
八、如何實現自動化部署

答：

一、一個域上加載的腳本獲取或操做另外一個域上的文檔屬性，跨域問題是因爲javascript語言安全限制中的同源策略形成的.

簡單來講,同源策略是指一段腳本只能讀取來自同一來源的窗口和文檔的屬性,這裏的同一來源指的是主機名、協議和端口號的組合.

參考 跨域原理及解決方案

二、

　　1.對查詢進行優化，要儘可能避免全表掃描，首先應考慮在 where 及 order by 涉及的列上創建索引。

　　2.應儘可能避免在 where 子句中對字段進行 null 值判斷，不然將致使引擎放棄使用索引而進行全表掃描，如：
　　　　select id from t where num is null
　　　　最好不要給數據庫留NULL，儘量的使用 NOT NULL填充數據庫.
　　　　備註、描述、評論之類的能夠設置爲 NULL，其餘的，最好不要使用NULL。
　　　　不要覺得 NULL 不須要空間，好比：char(100) 型，在字段創建時，空間就固定了， 無論是否插入值（NULL也包含在內），都是佔用 100個字符的空間的，若是是varchar這樣的變長字段， null 不佔用空間。
　　　　能夠在num上設置默認值0，確保表中num列沒有null值，而後這樣查詢：
　　select id from t where num = 0
　　3.應儘可能避免在 where 子句中使用 != 或 <> 操做符，不然將引擎放棄使用索引而進行全表掃描。
　　4.應儘可能避免在 where 子句中使用 or 來鏈接條件，若是一個字段有索引，一個字段沒有索引，將致使引擎放棄使用索引而進行全表掃描，如：
　　select id from t where num=10 or Name = 'admin'
　　　　能夠這樣查詢：
　　　　select id from t where num = 10
　　　　union all
　　　　select id from t where Name = 'admin'
　　5.in 和 not in 也要慎用，不然會致使全表掃描，如：
　　　　select id from t where num in(1,2,3)
　　　　對於連續的數值，能用 between 就不要用 in 了：
　　　　select id from t where num between 1 and 3
　　　　不少時候用 exists 代替 in 是一個好的選擇：
　　　　select num from a where num in(select num from b)
　　　　用下面的語句替換：
　　　　select num from a where exists(select 1 from b where num=a.num)
　　6.下面的查詢也將致使全表掃描：
　　　　select id from t where name like ‘%abc%’
　　　　若要提升效率，能夠考慮全文檢索。
　　7.若是在 where 子句中使用參數，也會致使全表掃描。由於SQL只有在運行時纔會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然 而，若是在編譯時創建訪問計劃，變量的值仍是未知的，於是沒法做爲索引選擇的輸入項。以下面語句將進行全表掃描：
　　　　select id from t where num = @num
　　　　能夠改成強制查詢使用索引：
　　　　select id from t with(index(索引名)) where num = @num
　　　　應儘可能避免在 where 子句中對字段進行表達式操做，這將致使引擎放棄使用索引而進行全表掃描。如：
　　　　select id from t where num/2 = 100
　　　　應改成:
　　　　select id from t where num = 100*2
　　9.應儘可能避免在where子句中對字段進行函數操做，這將致使引擎放棄使用索引而進行全表掃描。如：
　　　　select id from t where substring(name,1,3) = ’abc’ -–name以abc開頭的id
　　　　select id from t where datediff(day,createdate,’2005-11-30′) = 0 -–‘2005-11-30’ --生成的id
　　　　應改成:
　　　　select id from t where name like 'abc%'
　　　　select id from t where createdate >= '2005-11-30' and createdate < '2005-12-1'
　　10.不要在 where 子句中的「=」左邊進行函數、算術運算或其餘表達式運算，不然系統將可能沒法正確使用索引。
　　11.在使用索引字段做爲條件時，若是該索引是複合索引，那麼必須使用到該索引中的第一個字段做爲條件時才能保證系統使用該索引，不然該索引將不會被使用，而且應儘量的讓字段順序與索引順序相一致。
　　12.不要寫一些沒有意義的查詢，如須要生成一個空表結構：
　　　　select col1,col2 into #t from t where 1=0
　　　　這類代碼不會返回任何結果集，可是會消耗系統資源的，應改爲這樣：
　　　　create table #t(…)
　　13.Update 語句，若是隻更改一、2個字段，不要Update所有字段，不然頻繁調用會引發明顯的性能消耗，同時帶來大量日誌。
　　14.對於多張大數據量（這裏幾百條就算大了）的表JOIN，要先分頁再JOIN，不然邏輯讀會很高，性能不好。
　　15.select count(*) from table；這樣不帶任何條件的count會引發全表掃描，而且沒有任何業務意義，是必定要杜絕的。
　　16.索引並非越多越好，索引當然能夠提升相應的 select 的效率，但同時也下降了 insert 及 update 的效率，由於 insert 或 update 時有可能會重建索引，因此怎樣建索引須要慎重考慮，視具體狀況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有 必要。
　　17.應儘量的避免更新 clustered 索引數據列，由於 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將致使整個表記錄的順序的調整，會耗費至關大的資源。若應用系統須要頻繁更新 clustered 索引數據列，那麼須要考慮是否應將該索引建爲 clustered 索引。
　　18.儘可能使用數字型字段，若只含數值信息的字段儘可能不要設計爲字符型，這會下降查詢和鏈接的性能，並會增長存儲開銷。這是由於引擎在處理查詢和連 接時會逐個比較字符串中每個字符，而對於數字型而言只須要比較一次就夠了。
　　19.儘量的使用 varchar/nvarchar 代替 char/nchar ，由於首先變長字段存儲空間小，能夠節省存儲空間，其次對於查詢來講，在一個相對較小的字段內搜索效率顯然要高些。
　　20.任何地方都不要使用 select * from t ，用具體的字段列表代替「*」，不要返回用不到的任何字段。
　　21.儘可能使用表變量來代替臨時表。若是表變量包含大量數據，請注意索引很是有限（只有主鍵索引）。
　　22. 避免頻繁建立和刪除臨時表，以減小系統表資源的消耗。臨時表並非不可以使用，適當地使用它們可使某些例程更有效，例如，當須要重複引用大型表或經常使用表中的某個數據集時。可是，對於一次性事件， 最好使用導出表。
　　23.在新建臨時表時，若是一次性插入數據量很大，那麼可使用 select into 代替 create table，避免形成大量 log ，以提升速度；若是數據量不大，爲了緩和系統表的資源，應先create table，而後insert。
　　24.若是使用到了臨時表，在存儲過程的最後務必將全部的臨時表顯式刪除，先 truncate table ，而後 drop table ，這樣能夠避免系統表的較長時間鎖定。
　　25.儘可能避免使用遊標，由於遊標的效率較差，若是遊標操做的數據超過1萬行，那麼就應該考慮改寫。
　　26.使用基於遊標的方法或臨時表方法以前，應先尋找基於集的解決方案來解決問題，基於集的方法一般更有效。
　　27.與臨時表同樣，遊標並非不可以使用。對小型數據集使用 FAST_FORWARD 遊標一般要優於其餘逐行處理方法，尤爲是在必須引用幾個表才能得到所需的數據時。在結果集中包括「合計」的例程一般要比使用遊標執行的速度快。若是開發時 間容許，基於遊標的方法和基於集的方法均可以嘗試一下，看哪種方法的效果更好。
　　28.在全部的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每一個語句後向客戶端發送 DONE_IN_PROC 消息。
　　29.儘可能避免大事務操做，提升系統併發能力。
　　30.儘可能避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
　　　　實際案例分析：拆分大的 DELETE 或INSERT 語句，批量提交SQL語句
　　　　若是你須要在一個在線的網站上去執行一個大的 DELETE 或 INSERT 查詢，你須要很是當心，要避免你的操做讓你的整個網站中止相應。由於這兩個操做是會鎖表的，表一鎖住了，別的操做都進不來了。
　　　　Apache 會有不少的子進程或線程。因此，其工做起來至關有效率，而咱們的服務器也不但願有太多的子進程，線程和數據庫連接，這是極大的佔服務器資源的事情，尤爲是內存。
　　　　若是你把你的表鎖上一段時間，好比30秒鐘，那麼對於一個有很高訪問量的站點來講，這30秒所積累的訪問進程/線程，數據庫連接，打開的文件數，可能不只僅會讓你的WEB服務崩潰，還可能會讓你的整臺服務器立刻掛了。
　　　　因此，若是你有一個大的處理，你必定把其拆分，使用 LIMIT oracle(rownum),sqlserver(top)條件是一個好的方法。下面是一個mysql示例：

while(1){
//每次只作1000條
mysql_query(「delete from logs where log_date <= ’2012-11-01’ limit 1000」);
if(mysql_affected_rows() == 0){
//刪除完成，退出！
break；
}
//每次暫停一段時間，釋放表讓其餘進程/線程訪問。
usleep(50000)
}

 

　　參考 數據庫優化總結

　　參考 數據庫設計與性能優化

 三、值類型是直接存儲在內存的棧中的，引用類型在棧中存放一個地址，這個地址指向堆中的數據（引用類型的數據是存放在堆中的）

　　值類型均隱式派生於System.ValueType，System.ValueType直接派生於System.Object，引用類型基類爲Objcet

　　ref,out:傳遞值類型的變量的地址

　　ref:傳遞過程當中保留初始值，通常須要把外部的值傳入到方法中使用並進行修改

　　out:傳遞過程當中不保留初始值，通常傳遞變量進入某個方法中接收數據

　　值類型：struct、int/sbyte/short/long/byte/ushort/uint/ulong/char、float/double/deciaml、bool、enum

　　引用類型：數組、類、接口、委託、字符串

string value = "ab";
int num;
//out傳遞也是變量的地址，內部給這個變量賦值
if (int.TryParse(value, out num))//轉換成功就返回true，並把結果存儲在變量num中
{
    Console.WriteLine("轉換成功：" + num);
}
else {
    Console.WriteLine("轉換失敗");
}

　　

相同點：
　　引用類型能夠實現接口，值類型當中的結構體也能夠實現接口；
　　引用類型和值類型都繼承自System.Object類。
1）範圍方面
　　C#的值類型包括：結構體（數值類型、bool型、用戶定義的結構體），枚舉，可空類型。
　　C#的引用類型包括：數組，用戶定義的類、接口、委託，object，字符串。
2）內存分配方面：
　　數組的元素無論是引用類型仍是值類型，都存儲在託管堆上。
　　引用類型在棧中存儲一個引用，其實際的存儲位置位於託管堆。簡稱引用類型部署在託管推上。而值類型老是分配在它聲明的地方：做爲字段時，跟隨其所屬的變量（實 例）存儲；做爲局部變量時，存儲在棧上。（棧的內存是自動釋放的，堆內存是.NET中會由GC來自動釋放）
3）適用場合
　　值類型在內存管理方面具備更好的效率，而且不支持多態，適合用作存儲數據的載體；引用類型支持多態，適合用於定義應用程序的行爲。
　　引用類型能夠派生出新的類型，而值類型不能，由於全部的值類型都是密封（seal）的；
　　引用類型能夠包含null值，值類型不能（可空類型功能容許將 null 賦給值類型，如 int? a = null; ）；
　　引用類型變量的賦值只複製對對象的引用，而不復制對象自己。而將一個值類型變量賦給另外一個值類型變量時，將複製包含的值。
　　值得注意的是，引用類型和值類型都繼承自System.Object類。不一樣的是，幾乎全部的引用類型都直接從System.Object繼承，而值類型則繼承其子類，即 直接繼承System.ValueType。即System.ValueType自己是一個類類型，而不是值類型。其關鍵在於ValueType重寫了Equals()方法，從而對值類型按照實例的值來比較，而不是引用地址來比較。

四、微服務架構中的任何一個環節，都是能夠說好久。

　　微服務主要體現的是單一職責和關注分離的思想，從單進程模塊化進一步拓展到跨進程分佈式的模塊化。微服務是獨立的開發、測試、部署和升級單元，正如我在第一點架構定義中提到的，微服務中每一個服務能夠獨立演變，它的cost of change比較小，總體架構比較靈活，是一種支持創新的演化式架構。

上圖講何時該引入微服務。微服務有額外成本的，須要搭建框架、發佈、監控等基礎設施。初創和小規模團隊不建議採用。主要決定因素系統複雜性和團隊規模，當到達一個點，單塊架構嚴重影響效率才考慮 。另外補充一點，微服務更可能是關於組織和團隊，而不是技術。即架構和組織文化關係。

下圖是微服務實施的過程當中涉及到的層次

階段一單體架構羣，多個開發組，統一運維組

傳統煙囪式架構

傳統架構的中間件層，每一個團隊獨立選型中間件：
文件：NFS，FTP，Ceph，S3
緩存：Redis Cluster，主備，Sentinel, Memcached
分佈式框架：Spring Cloud，Dubbo，Restful or RPC不一樣的部門本身選型
分庫分表：Sharding-jdbc，Mycat
消息隊列：RabbitMQ, Kafka
註冊中心：Zk，Euraka，consul
傳統架構的服務層，系統或者由外包公司開發，或者由獨立團隊開發。

微服務階段二

 4.二、網關

　　Demo

　　.NET Core微服務之基於Ocelot實現API網關服務

　　談談微服務中的API網關

　　Ocelot + Consul實踐

　　.NET微服務直播課課件pdf

　　.NET Core開源API網關 – Ocelot中文文檔

 4.三、服務註冊和服務發現都是Consul自有的功能，能夠經過Consul的http api完成註冊或發現