一、有文件file1
1. 查詢file1里面空行所在的行號；
答：grep -n ‘^$’ file1
2. 查詢file1中以abc結尾的行；
答：grep ‘a(chǎn)bc$’ file1
3. 打印file1 文件的第一到三行；
答：sed ?-n ‘1，3’p file1
二、寫一條放行80端口的防火墻規(guī)則。
答：iptables -I INPUT -p tcp --dport 80 -j ACCEPT
三、寫一條192.168.10.0網(wǎng)段從網(wǎng)關192.168.9.1出去的路由
答：route add -net 192.168.10.0/24 gw 192.168.9.1
四、 每天早上6點到12點，每隔2小時執(zhí)行一次/usr/bin/httpd.sh怎么實現(xiàn)
答：crontab -e 然后添加一行
0 6，8，10，12 * * * /bin/bash /usr/bin/httpd.sh
五、編寫個shell腳本判斷根目錄下有沒有abc目錄，如果沒有就發(fā)郵件給admin@121.com
答：#！/bin/bash
if [ ！ -d /abc ]
then
echo “Director /abc is gone， please check.”| mail -s ‘directory /abc is gone’ admin@121.com
fi
六、Raid0，raid1，raid5原理
答案參考第5套11題
七、備份mysql數(shù)據(jù)庫test庫
答：mysqldump -uroot -p’passwd’ test > /data/test.sql
八、如何查看占用端口8080的進程
答：lsof -i ：8080
九、Apache有幾種工作模式，分別介紹下其特點，并說明什么情況下采用不同的工作模式？
答案：Web服務器Apache目前一共有三種穩(wěn)定的MPM（Multi-Processing Module，多進程處理模塊）模式。它們分別是prefork，worker和event，它們同時也代表這Apache的演變和發(fā)展。使用httpd -V 命令查看。在configure配置編譯參數(shù)的時候，可以使用 --with-mpm=prefork|worker|event 來指定編譯為那一種MPM，當然也可以用編譯為三種都支持：--enable-mpms-shared=all，這樣在編譯的時候會在modules目錄下自動編譯出三個MPM文件的so，然后通過修改httpd.conf配置文件更改MPM。
1.Prefork MPM
Prefork MPM實現(xiàn)了一個非線程的、預派生的web服務器。它在Apache啟動之初，就先預派生一些子進程，然后等待連接；可以減少頻繁創(chuàng)建和銷毀進程的開銷，每個子進程只有一個線程，在一個時間點內(nèi)，只能處理一個請求。這是一個成熟穩(wěn)定，可以兼容新老模塊，也不需要擔心線程安全問題，但是一個進程相對占用資源，消耗大量內(nèi)存，不擅長處理高并發(fā)的場景。
2.Worker MPM
和prefork模式相比，worker使用了多進程和多線程的混合模式，worker模式也同樣會先預派生一些子進程，然后每個子進程創(chuàng)建一些線程，同時包括一個監(jiān)聽線程，每個請求過來會被分配到一個線程來服務。線程比起進程會更輕量，因為線程是通過共享父進程的內(nèi)存空間，因此，內(nèi)存的占用會減少一些，在高并發(fā)的場景下會比prefork有更多可用的線程，表現(xiàn)會更優(yōu)秀一些；另外，如果一個線程出現(xiàn)了問題也會導致同一進程下的線程出現(xiàn)問題，如果是多個線程出現(xiàn)問題，也只是影響Apache的一部分，而不是全部。由于用到多進程多線程，需要考慮到線程的安全了，在使用keep-alive長連接的時候，某個線程會一直被占用，即使中間沒有請求，需要等待到超時才會被釋放（該問題在prefork模式下也存在）。
3.Event MPM
這是Apache最新的工作模式，它和worker模式很像，不同的是在于它解決了keep-alive長連接的時候占用線程資源被浪費的問題，在event工作模式中，會有一些專門的線程用來管理這些keep-alive類型的線程，當有真實請求過來的時候，將請求傳遞給服務器的線程，執(zhí)行完畢后，又允許它釋放。這增強了在高并發(fā)場景下的請求處理。
十．簡述mysql主從復制過程
答：Mysql的 Replication 是一個異步的復制過程，從一個 Mysql instace(我們稱之為 Master)復制到另一個 Mysql instance(我們稱之 Slave)。在 Master 與 Slave 之間的實現(xiàn)整個復制過程主要由三個線程來完成，其中兩個線程(Sql線程和IO線程)在 Slave 端，另外一個線程(IO線程)在 Master 端。
要實現(xiàn) MySQL 的 Replication ，首先必須打開 Master 端的Binary Log(mysql-bin.xxxxxx)功能，否則無法實現(xiàn)。因為整個復制過程實際上就是Slave從Master端獲取該日志然后再在自己身上完全順序的執(zhí)行日志中所記錄的各種操作。打開MySQL的 Binary Log可以通過在啟動MySQL Server的過程中使用“l(fā)og-bin”參數(shù)選項，或者在my.cnf配置文件中的mysqld參數(shù)組([mysqld]標識后的參數(shù)部分)增加 “l(fā)og-bin” 參數(shù)項。
MySQL復制的基本過程如下：
1.Slave上面的IO線程連接上Master，并請求從指定日志文件的指定位置(或者從最開始的日志)之后的日志內(nèi)容；
2.Master接收到來自Slave的IO線程的請求后，通過負責復制的IO線程根據(jù)請求信息讀取指定日志指定位置之后的日志信息，返回給Slave端的IO線程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息在Master端的Binary Log文件的名稱以及在Binary Log中的位置；
3.Slave的IO線程接收到信息后，將接收到的日志內(nèi)容依次寫入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端，并將讀取到的Master端的bin-log的文件名和位置記錄到master- info文件中，以便在下一次讀取的時候能夠清楚的高速Master“我需要從某個bin-log的哪個位置開始往后的日志內(nèi)容，請發(fā)給我”
4.Slave的SQL線程檢測到Relay Log中新增加了內(nèi)容后，會馬上解析該Log文件中的內(nèi)容成為在Master端真實執(zhí)行時候的那些可執(zhí)行的Query語句，并在自身執(zhí)行這些Query。這樣，實際上就是在Master端和Slave端執(zhí)行了同樣的Query，所以兩端的數(shù)據(jù)是完全一樣的。
