运维面试宝典

【Linux基础篇】

1.描述Linux运行级别0-6的各自含义

0 ：关机模式

1 ：单用户模式 <== 破解 root 密码

2 ：无网络支持的多用户模式

3 ：有网络支持的多用户模式（文本模式，工作中最常用的模式）

4 ：保留，未使用

5 ：有网络支持的 X‐windows 支持多用户模式（桌面）

6 : 重新引导系统，即重启

2.描述Linux系统从开机到登陆界面的启动过程

1. 开机 BIOS 自检，加载硬盘。

2. 读取 MBR,MBR 引导。

3. grub 引导菜单 (Boot Loader) 。

4. 加载内核 kernel 。

5. initプロセスを 開始し 、inittabファイルに従って実行レベルを設定します。

6. init プロセスは rc.sysinit ファイルを実行します。

7. カーネル モジュールを起動し、さまざまなレベルでスクリプトを実行します。

8. /etc/rc.d/rc.local を実行します _ _ _ _ _

9. mingetty を起動し 、システムのログイン インターフェイスに入ります。

3. Linuxにおけるソフト リンクとハード リンクの違いについて説明します。

Linuxシステム には 2 種類のリンクがあり、1 つはハード リンク ( ハード リンク)、もう 1 つはシンボリック リンクまたはソフト リンク ( シンボリック リンク) と呼ばれます 。

1. デフォルトでは、 パラメータを指定しない ln は ハード リンクを作成し、 -s パラメータを指定したlnコマンドはソフト リンクを作成します。

2.ハードリンクファイルの iノード番号 はソースファイルと同じです が、ソフトリンクファイルのiノード番号はソースファイルと異なります。

3.l n 命令不能对目录创建硬链接，但可以创建软链接。对目录的软链接会经常使用到。

4. 删除软链接文件，对源文件和硬链接文件无任何影响。

5. 删除文件的硬链接文件，对源文件及软链接文件无任何影响。

6. 删除链接文件的源文件，对硬链接文件无影响，会导致其软链接失效（红底白字闪烁状）。

7. 同时删除源文件及其硬链接文件，整个文件才会被真正的删除。

8. 很多硬件设备的快照功能，使用的就是类似硬链接的原理。

9. 软链接可以跨文件系统，硬链接不可以跨文件系统。

4.如果一台办公室内主机无法上网（打不开网站），请给出你的排查步骤？

1. 首先确定物理链路是否联通正常。

2. 查看本机 IP ，路由， DNS 的设置情况是否达标。

3. telnet 检查服务器的 WEB 有没有开启以及防火墙是否阻拦。

4. ping 一下网关，进行最基础的检查，通了，表示能够到达服务器。

5. 测试到网关或路由器的通常情况，先测网关，然后再测路由器一级一级的测试。

6. 测试 ping 公网 ip 的通常情况（记住几个外部 IP ），

7. 测试 DNS 的通畅。 ping 出对应 IP 。

8. 通过以上检查后，还在网管的路由器上进行检查。

5.网站打开慢，请给出排查方法，如是数据库慢导致，如何排查并解决，请分析并举例？

1 、可以使用 top free 等命令分析系统性能等方面的问题

2 、如是因为数据库的原因造成的，就需要查看慢查询日志去查找并分析问题所在

6.如何选择Linux操作系统版本?

一般来讲，桌面用户首选 Ubuntu ；服务器首选 RHEL 或 CentOS ，两者中首选 CentOS 。

根据具体要求：

1. 安全性要求较高，则选择 Debian 或者 FreeBSD 。

2. 高度なデータベース サービスと電子メール ネットワーク アプリケーションを使用する必要があるユーザーは、 SUSEを選択できます 。

3.新しいテクノロジーや新しい機能が必要な場合は、 Feddora を 選択できます 。Feddoraは、 RHELおよびCentOSのベータ版およびプレリリース版です。

4. 現在の状況によれば、インターネット企業の大多数が CentOS を選択しています 。 現在では6シリーズの 方が一般的に使用されており 、市場の約半分を占めています。その他の理由

CentOS は サーバー分野に重点を置いており、著作権の制限はありません。

7.運用シナリオでLinuxシステムを適切に計画および分割するにはどうすればよいですか?

パーティショニングの基本原理は、シンプルさ、使いやすさ、そして便利なバッチ管理です。サーバーの役割に基づいた配置の提案は次のとおりです。

1. スタンドアロンサーバー: 8 G メモリ、 300 G ハードディスクなど

パーティション: / boot 100-200M 、swap 16G 、メモリサイズ 8G * 2 、/ 80G 、/ var 20G (分割も可能) 、/ data 180G ( WebおよびDBデータを保存)

メリット：データディスクとシステムディスクが分離されているため、トラブル時のメンテナンスに役立ちます。

RAID ソリューション: データとパフォーマンスの要件に応じて、通常は 妥協案として RAID5を使用できます。

2. ロードバランサ（ LVS など）

パーティション: / ブート 100-200 M 、スワップメモリの1-2倍、 / 、 _

利点: シンプルで便利、少量のデータのみを転送します。

RAID ソリューション: データ量が小さく重要性が高いため、 RAID1を使用できます。

3. 負荷分散中の RS サーバー

パーティション: / ブート 100-200 M 、スワップ メモリ の1-2倍 、 / _

利点: シンプルで便利。複数のマシンがあるため、データ要件が低くなります。

RAID ソリューション: データ量が多く、重要度が高くなく、パフォーマンス要件があり、データ要件が低い場合、 RAID0を使用できます。

4. データベース サーバー mysql および oracle など 16/32 G メモリ _

分区： / boot 100 ‐ 200 M ， swap 16 G ，内存的 1 倍， / 100 G ， / data 剩余（存放 db 数据）

优点：数据盘和系统盘分开，有利于出问题时维护 , 及保持数据完整。

RAID 方案：视数据及性能要求主库可采取 raid10 / raid5 ，从库可采用 raid0 提高性能（读写分离的情况下。）

5. 存储服务器

パーティション: / boot 100-200M 、スワップメモリ​​の1-2倍 、 / 100G 、/ data (ストレージ データ ) _ _

利点: このサーバーにはパーティションが多すぎません。バックアップのみが行われ、パフォーマンス要件は低くなります。容量は大きいほうがいいです。

RAID ソリューション: SATA ディスク、 RAID5を使用可能

6.共有ストレージサーバー ( NFS など )

パーティション: / boot 100-200M 、スワップメモリ​​の1-2倍 、 / 100G 、/ data (ストレージ データ ) _ _

利点: このサーバーにはパーティションが多すぎません。 NFS 共有の要件は、ストレージ以上にパフォーマンス要件です。

RAIDソリューション: パフォーマンスとアクセス要件に応じて、 RAID5、RAID10、またはRaid0 にすることもできます (高可用性またはデュアル書き込みソリューションが必要です)。

7. 監視サーバー cacti、nagios

パーティション: / ブート 100-200 M 、スワップ メモリ の1-2倍 、 / _

利点: 平均的な重要性、平均的なデータ要件。

RAID スキーム: シングル ディスクまたはダブル ディスクの RAID1 で十分です。3 つのディスクは RAID5であり 、容量要件に応じてさらにディスクを追加できます。

8. Linuxサーバーの現在の実行レベルを確認するにはどうすればよいですか?

「 who ‐r 」コマンド と「runlevel 」コマンド を使用して、 Linuxサーバーの現在のランレベルを表示できます。

9. Linuxシステムのバージョンを確認する方法を簡単に説明してください

うなめ - a

10. Linuxの実行時間を確認する

稼働時間

11.システム管理者は、毎日特定の反復的なタスクを実行する必要があるため、次の要件に従ってソリューションを準備してください。

( 1 ) 午後 4 時 50 分に、 / abcディレクトリ内のすべての サブディレクトリ とすべてのファイルを削除します。

( 2 )朝8 時 から午後 6 時までに、/xyz ディレクトリにある x1 ファイルの各行の最初のフィールドのデータをすべて読み取り、/xyz ディレクトリにある bak01.txtファイルに追加します。バックアップディレクトリ;

( 3 ) 毎週月曜日の午後 5 時 50 分に 、 / data ディレクトリ内のすべてのディレクトリとファイルがアーカイブされ、次のファイルに 圧縮されます 。

( 1 ) crontab ‐ e 50 16 * * * rm ‐ rf / abc /

( 2 ) * 8 ‐ 18 / 1 * * * awk '{print $1 > "/backup/bak01.txt"}' / xyz / x1

( 3 ) 50 17 * * 1 tar ‐ czf Backup.tar.gz / data

12. 3月23日21時18分にサーバーを再起動してください。

crontab - e 18 21 23 3 * init 6

13. Linuxのデフォルトゲートウェイを確認するにはどうすればよいですか?

「 route -n 」および「netstat -nr 」コマンドを使用すると、デフォルト ゲートウェイを表示できます 。

これら 2 つのコマンドは、デフォルト ゲートウェイ情報に加えて、現在のルーティング テーブルも表示できます。

14.フォルダー内のiノードの数を確認するにはどうすればよいですか?

find / ‐ xdev ‐ printf '%h\n' | 並べ替え | ユニーク - c | ソート ‐ k 1 ‐ n

15.最終作成時刻が3日前でサフィックスが*.logであるファイルを検索して削除するスクリプトを作成します。

find / ‐ name “ * .log ” ‐ ctime + 3 ‐ exec rm ‐f {} \ ;

16.如果某文件夹下文件太多无法ls该如何解决？

ls ‐f

17.如何用tcpdump嗅探80端口的访问看看谁最高？

tcpdump - i eth0 - tnn dst ポート 80 - c 1000 | awk ‐F 」 。 ” ' {print $1 ″ 。 「 2ドル 」 。 「 3ドル 」 。 「 4ドル 」 。 ” } ' | 並べ替え | ユニークな

‐ c | ソート ‐ nr | ヘッド-5

18. /var/logディレクトリ内のファイルの数を確認するにはどうすればよいですか?

ls / var / log / ‐ 1 R | grep “ - ” | トイレ - l

19. Linuxシステムで各IPの接続数を確認するにはどうすればよいですか?

netstat - n | awk ' /^ tcp / {print $5 } ' | awk ‐F: ' {print $1 } ' | 並べ替え | ユニーク - c | ソート - rn

20.シェルで32桁のランダムなパスワードを生成します

猫 / 開発 / ウランダム | ヘッド ‐ 1 | md5sum | head ‐ c 32 >> / パス

21. Apacheのaccess.logで最もアクセス数の多い5 つのIPを数えます

猫の アクセスログ | awk ' {print $1 } ' | 並べ替え | ユニーク - c | ソート ‐ n ‐ r | ヘッド ‐ 5

22. Linuxシステムで環境変数を設定するには複数の方法を使用し、さまざまな方法の違いを指摘してください。

1. コンソールで設定します。この方法は現在の シェルでのみ機能するためサポートされていません。 シェル設定 の変更 は無効になります: PATH = "PATH" :/ NEW_PATH (シェル パスを閉じると元のパスに戻ります)

2. / etc /プロファイルファイル を変更します 。コンピュータが開発のみに使用されている場合は、すべてのユーザーシェルがこの環境変数を使用する権利を持っているため、この方法を使用してください。これにより、システムのセキュリティ上の問題が発生する可能性があります。これはすべてのユーザーを対象としています。すべてのシェルの場合は、 / etc / profileの最後に次のように追加します。export PATH = " $PATH: /NEW_PATH"

3. bashrcファイル を変更します 。この方法はより安全です。これらの環境変数を使用する権限をユーザー レベルに制御できます。これは特定のユーザー用です。これらの環境変数を使用する権限をユーザーに与える必要がある場合は、個人ユーザーのホーム ディレクトリにある.bashrcファイルを変更するだけです。以下を追加します: Export PATH = " $PATH: /NEW_PATH"

【基本サービス】

23.リモート ホストがローカル マシンのポート80にアクセスすることのみを許可するファイアウォール構成スクリプトを作成します。

iptables - P 入力受け入れ

iptables - P 出力受け入れ

iptables - P 転送受け入れ

iptables -F

iptables - X

iptables - A INPUT - i eth0 - p tcp - dport 80 - j ACCEPT

iptables - P 入力ドロップ

24.リクエストをローカルポート80からポート8080に転送する方法。現在のホストIPは192.168.2.1です。

/ sbin / iptables - t nat - A PREROUTING - p tcp - - dport 80 - j DNAT - - 192.168.2.1 : 8080

/ sbin / iptables - t nat - A PREROUTING - p tcp--dport 80 - j REDIRECT - - 8080 へ

25.一般的に使用されるサービス ポートを5つ以上挙げる

21 ‐‐‐‐‐‐ ftp                   22 ‐‐‐‐‐‐ ssh                 23 ‐‐‐‐‐‐ telnet

25 ‐‐‐‐‐‐ snmp               110 ‐‐‐‐‐ ppop3            143 ‐‐‐‐‐ IMAP

873 ‐‐‐‐‐ rsync              80 ‐‐‐‐‐‐ http                3306 ‐‐‐‐‐‐ mysql

26. FTPのアクティブモードとパッシブモード

FTPプロトコルには、 PORTモードとPASVモードという 2 つの動作モードがあります。PASV モードは、中国語でアクティブとパッシブを意味します。

‐アクティブ モード

1. クライアントは、 1023より大きい ランダム コマンド ポートと 1023より大きいランダム データ ポートを開き、 サービスポート 21への 要求を開始します。

2. サーバー == のコマンド ポート番号21 は、クライアントのランダムなコマンド ポート に応答します。

3. == サーバー の ポート番号20 ==== Active ==は、クライアントに 接続するためのランダムなデータ ポートを要求します

4. 確認用のクライアントのランダム データ ポート

‐パッシブ モード

1. クライアントは、 1023より大きい ランダム コマンド ポートと 1023より大きいランダム データ ポートを開き、 サービスポート 21への 要求を開始します。

2. サーバーのコマンド ポート 21番は 、クライアントのランダムなコマンド ポートに応答します。

3. == クライアントアクティブ == サーバーによって開かれた 1023より大きい ランダムなポートに接続します

4. サーバーが確認します

27. sshパスワード不要のログインプロセスについて簡単に説明してください。

1. サーバー A で公開キーと秘密キーを生成します。

2. 公開キーを サーバー Bにコピーし、名前を authorized_keys に変更します。

3. サーバー A が サーバー B に 接続要求を送信します。

4. サーバー B は サーバー Aの情報を 取得した後、 authorized_keyでそれを比較し、一致するユーザー名とIPがあれば、ランダムに文字列を生成し、サーバー Aの公開鍵で暗号化してサーバー Aに送信します。 。

5. サーバー A は サーバー Bからメッセージ を取得した後、 秘密キーを使用してメッセージを復号化し、復号化された文字列をサーバー Bに送信します。サーバー B が生成した結果とサーバー B が生成した結果を比較し、それらが一致していれば、ログインフリーが許可されます。

28. tcpの3 -way ハンドシェイクと4 -way waveの全プロセス

( 1 ) 最初のハンドシェイク: クライアントは フラグ SYNを 1 に設定し 、値seq = Jをランダムに生成し、データ パケットをサーバーに送信し、クライアントはSYN_SENT状態に入り、サーバーからの確認を待ちます。

（ 2 ）第二次握手： Server 收到数据包后由标志位 SYN = 1 知道 Client 请求建立连接， Server 将标志位 SYN 和 ACK 都置为 1 ， ack = J + 1 ，随机产生一个值 seq = K ，并将该数据包发送给 Client 以确认连接请求， Server 进入 SYN_RCVD 状态。

( 3 ) 3 回目のハンドシェイク: クライアントは確認を受信し た後、 ack が J + 1であるかどうか 、および ACKが 1 であるかどうかを確認します。それが正しい場合は、フラグ ACK を1に設定し、ack = K + 1に設定します。データ パケットを送信します。サーバーに対して、サーバーはACKがK + 1であるかどうか、およびACK が1であるかどうかを確認します。正しければ、接続は正常に確立されます。クライアントとサーバーはESTABLISHED状態に入り、3 ウェイ ハンドシェイクを完了します。その後、クライアントとサーバーはデータの送信を開始できるようになります。

( 1 ) 第 1 波: クライアントは FIN を送信して クライアントからサーバーへのデータ送信を終了し、クライアントはFIN_WAIT_1状態に入ります。

( 2 ) 第 2 波: FINを受信した後、 サーバーは クライアントにACKを送信し、確認シーケンス番号は受信したシーケンス番号+ 1 ( SYNと同じ、1 つのFIN が1 つのシーケンス番号を占有します) となり、サーバーは開始します。CLOSE_WAIT状態。

( 3 ) 第 3 の波: サーバーは FIN を送信して サーバーからクライアントへのデータ送信を終了し、サーバーはLAST_ACK状態に入ります。

（ 4 ）第四次挥手： Client 收到 FIN 后， Client 进入 TIME_WAIT 状态，接着发送一个 ACK 给 Server ，确认序号为收到序号 + 1 ， Server 进入 CLOSED 状态，完成四次挥手。

29.请写出http和https请求的区别，并写出遇到过的响应状态码

1. https 协议需要到 ca 申请证书，一般免费证书很少，需要交费。

2. http 是超文本传输协议，信息是明文传输， https 则是具有安全性的 ssl 加密传输协议。

3. http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80 ，后者是 443 。

4. http 的连接很简单，是无状态的； HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。

状态码常用：

301 永久重定向

403 服务器已经理解请求，但是拒绝执行

404 页面丢失

500 服务器错误

30.操作系统内存调度方式有哪几种并简单说明

OPT ：最佳替换算法（ optional replacement ）。替换下次访问距当前时间最长的页。 opt 算法需要知道操作系统将来的 事件，显然不可能实现，只作为一种衡量其他算法的标准。

LRU : 最近最少使用 (Least Recently Used). 替换上次使用距离当前最远的页。根据局部性原理：替换最近最不可能访 问到的页。性能最接近 OPT ，但难以实现。可以维护一个关于访问页的栈或者给每个页添加最后访问的时间标签，但开销 都很大。

FIFO : 先进先出 (First In First Out), 将页面看做一个循环缓冲区，按循环方式替换。

Clock ：时钟替换算法（ Clock ） , 给每个页帧关联一个使用位。当该页第一次装入内存或者被重新访问到时，将使用位置为 1 。每次需要替换时，查找使用位被置为 0 的第一个帧进行替换。

31.简述DNS进行域名解析的过程？

用户要访问 www.baidu.com ，会先找本机的 host 文件，再找本地设置的 DNS 服务器，如果也没有的话，就去网络中找根服 务器，根服务器反馈结果，说只能提供一级域名服务器 .cn ，就去找一级域名服务器，一级域名服务器说只能提供二级域名服务器 .com.cn, 就去找二级域名服务器，二级域服务器只能提供三级域名服务器 .baidu.com.cn ，就去找三级域名服务器，三级域名服务器正好有这个网 www.baidu.com ，然后发给请求的服务器，保存一份之后，再发给客户端

【shell编程篇】

32. Linux シェルにおける一重引用符、二重引用符、および引用符なしの簡単な違いについて説明してください

一重引用符: 表示される内容がそのまま取得されます。つまり、一重引用符内の内容がそのまま出力されるか、一重引用符内に表示される内容を出力するものとして記述されます。

ダブルクォーテーション：ダブルクォーテーションで囲まれた内容を出力します。内容にコマンドや変数等がある場合は、まず内容を変更し、コマンドを解析して結果を取得し、最終的な内容を出力します。

引用符なし: コンテンツを出力します。スペースを含む文字列はキー設定されず、出力全体として扱われます。コンテンツにコマンド、変数などが含まれる場合、変数とコマンドが最初に解析され、次に解析されます。文字列にスペースなどの特殊文字が含まれている場合、完全な出力ができないため、二重引用符を追加する必要があります。一般に、連続する文字列、数値、パスなどを使用できますが、代わりに二重引用符を使用することをお勧めします。

33.特定のディレクトリにある100kを超えるファイルを/tmpに移動するスクリプトを作成します。

for i の `find / test ‐ type f ‐ size + 100 k`; do cd / test && mv $i / tmp;done

34.写一个脚本进行nginx日志统计，得到访问ip最多的前10个(nginx日志路径：/home/logs/nginx/default/access.log

awk ‘ {a[ $1 ] ++ } END { for (j in a) print a[j],j} ’ / home / logs / nginx / default / access.log | sort ‐ nr | head

‐ 10

35.写一个脚本把指定文件里的/usr/local替换为别的目录

sed ‘ s: / user / local :/ tmp : g ’ filename

36.写一个脚本，实现批量添加20个用户，用户名为user01-20，密码为user后面跟5个随机字符

#!/bin/bash

#description: useradd

for i in `seq ‐f ” % 02 g ” 1 20 `; do

useradd user $i

echo " user $i- ` echo $RANDOM | md5sum | カット ‐ c 1 ‐ 5 ` ” | passwd – stdinuser $i >/ dev / null 2 >& 1

終わり

37. 192.168.1.0/24ネットワーク内で現在オンラインになっているIPを確認するスクリプトを作成します。pingできる場合は、オンラインとみなされます。

#!/bin/bash

`seq 1 255`のIP の 場合

する

ping ‐ c 1 192.168.1 . $ip > / dev / null 2 >& 1

if [ $? ‐eq 0 ]; then

echo 192.168.1 . $ip UP

else

echo 192.168.1 . $ip DOWN

fi

} &

done

wait

38.写一个脚本，判断一个指定的脚本是否是语法错误；如果有错误，则提醒用户键入Q或者q无视错误并退出其它任何键可以通过vim打开这个指定的脚本

#!/bin/bash

read ‐ p “ please input check script ‐> ” file

if [ ‐f $file ]; それから

sh ‐ n $file > / dev / null 2 >& 1

もし [ $? -ね 0 ]; それから

read ‐ p “ $file構文エラー を入力しました 。[終了するには q と入力するか、編集するには vim と入力してください] ”答え

case $answer in

q | 問）

0番出口

;;

ヴィム)

vim $file

;;

* ）

0番出口

;;

イーサック

フィ

それ以外

echo 「 $file が 存在しません 」

出口 1

フィ

39.現在のディレクトリ内のすべてのファイルの拡張子をログに変更するスクリプトを作成します。

` ls内の ファイル の場合。/ | grep ‐ P "(.*)(\..*)" `;

する

エコー $ファイル | mv $file ` echo ${file%.**} `.log;

終わり

【データベースサービス】

40.データベースをリモート サーバー192.168.1.1/backupディレクトリにバックアップしてパッケージ化するスクリプトを作成します。

マウント 192.168.1.1 :/ バックアップ / mnt

CD / MT

/ usr / local / mysql / bin / mysqldump ‐ hlocalhost ‐ uroot テスト > test.sql

tar czf test.sql.tar.gz test.sql

rm -f テスト.sql

41. mysqlデータベースにSQLクエリを作成して、 customerテーブルのuid列で100を超えるレコードを検索し、それらをuidでソートし、最初の10レコードを正の順序で出力してください。

select * from customer where uid > 100 uid asc limit 10で注文

42.データベースの読み取りと書き込みを分離する利点は何ですか?

1. 読み取り操作と書き込み操作を異なるデータベースに分離することで、データ アクセスの負荷を軽減し、パフォーマンスのボトルネックを回避します。

2. メイン サーバーが書き込み操作を実行する場合、クエリ アプリケーション サーバーのクエリ パフォーマンスに影響を与えず、ブロッキングが軽減され、同時実行性が向上します。

3. データには複数の災害復旧コピーがあり、データのセキュリティが向上すると同時に、メイン サーバーに障害が発生した場合は、すぐに他のサーバーに切り替えることができ、システムの可用性が向上します。

43.MongoDBとmysqlの違いは何ですか?

① MongoDB は _id を指定し なくても挿入が速く、システムメモリ使用率が高いため、読み込みタスクが重いタスクモデルに適していますが、安定性はmysqlに及びません。

② データの具体的な形式が不明瞭（データ構造が弱い）な場合に適しており、開発者に優しい。ただし、トランザクション関係のサポートは弱い ( NoSQLでよくある問題 )

③ 分散ファイルシステムを搭載しており、クラスタへの導入が容易です。

④ シャード（実データストレージ）の概念 シャードを追加する たびに 挿入性能がほぼ指数関数的に向上し、ディスク容量も容易に拡張できます。

⑤ シャード 分割には以下が含まれます: mongos ( クライアント要件 の受信 、シャードクラスターインターフェイス) config (各スライスのシャードキー範囲などのメタデータまたは構成情報、mongos は構成情報に基づいてデータを取得します)

44.Redisとmemcacheの違いとアプリケーションシナリオ

① redis はより豊富なデータ型をサポートしており、 合計5 つの型 (文字列、リスト、ハッシュ、セット、順序付きセット) があり、 memcache は単純な文字列のみをサポートしています

② Redis は データを永続化できます. データをメモリに保存するだけでなくディスクにも保存します. Memcache はデータをメモリに保存します. 最大保存量はメモリ サイズです.

③redis は マスター・スレーブにできる

④ Redis は 1 G まで 、memcache は1 Mまで保存できます。

Redis アプリケーションのシナリオ

① セッション ：永続化可能

② フルページキャッシュ ( FPC ): 永続的で、再起動後も、ユーザーに表示される Web ページの速度は低下しません。

③ list と set は Redisでメッセージキューとして 利用可能

⑤ ランキングリスト、 セット 、 zset は数値ソートをうまく実行できます

⑥パブリッシュ / サブスクライブ 機能

Redis に関する注意事項:

① Redisマスター では永続化を行わないことをお勧めしますが、スレーブ マシンでは永続化 ( AOF ) を実行できます (ポリシーは 1 秒に 1 回)。

② マスターとスレーブの安定性を確保するには、マスターとスレーブが同じネットワークセグメントにあることが最適です。

③過度に ストレスがかかる Redisマスター にスレーブマシンを追加しないようにしてください。

④マスター/スレーブ レプリケーションの場合は、グラフィカル構造を使用しないでください。単一のリンク リストを使用する方が安定しており、単一点障害の問題を簡単に解決できます。マスターに障害が発生した場合は、 slave1 を 直接マスターに昇格させます 。

45.redisデータ構造

string - 文字列タイプ、使用シナリオ: キャッシュ、カウンター、および セッションの共有

hash - ハッシュ タイプ、使用シナリオ: ユーザー情報ストレージ

list - リストの種類、使用シナリオ: メッセージ キュー、Weibo TimeLine

set ‐‐‐‐ コレクションタイプ、使用シナリオ: 友人の推薦

ソートセット - ソートセットタイプ、使用シナリオ: ランキングリスト

46.実稼働環境におけるRedis用のオープンソースの高可用性ソリューションは何ですか?

1. Twemproxy は 、一般的な概念はプロキシ メソッドに似ており、その使用方法は通常の redis と変わりません。その配下に複数の redis インスタンス を設定した後、使用する場合は、 redisに接続するのではなくtwemproxyに接続します。はリクエストをプロキシとして受信し、一貫したハッシュアルゴリズムを使用してリクエストを特定のredisに転送し、結果をtwemproxyに返します。これは使いやすく( redisと比較して、接続ポートを変更するだけで済みます) 、古いプロジェクトを拡張するための最初の選択肢です。問題: twemproxy自身の単一ポート インスタンスの圧力により、コンシステント ハッシュを使用した後、redisノードの数が変化すると計算値が変化し、データを新しいノードに自動的に移動できなくなります。

2. 現在最も一般的に使用されているクラスター ソリューションである Codis は、基本的に twemproxyと同じ効果がありますが、ノード数が変化した場合に古いノード データを新しいハッシュノードに復元することをサポートします。

3. Redis cluster3 .0 自带的集群，特点在于他的分布式算法不是一致性 hash ，而是 hash 槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。

4. 在业务代码层实现，起几个毫无关联的 redis 实例，在代码层，对 key 进行 hash 计算，然后去对应的 redis 实例操作数据。 这种方式对 hash 层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实 例的监控，等等。

5. Redis 哨兵， Redis Sentinal 着眼于高可用，在 master 宕机时会自动将 slave 提升为 master ，继续提供服务。

47.Redis是单线程的，如何提高多核CPU的利用率？

可以在同一个服务器部署多个 Redis 的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个 CPU ，你可以考虑一下分片（ shard ）。

48.Redis常见性能问题和解决方案？

1. Master 最好不要做任何持久化工作，如 RDB 内存快照和 AOF 日志文件

2. 如果数据比较重要，某个 Slave 开启 AOF 备份数据，策略设置为每秒同步一次

3. 为了主从复制的速度和连接的稳定性， Master 和 Slave 最好在同一个局域网内

4. 尽量避免在压力很大的主库上增加从库

5. 主从复制不要用图状结构，用单向链表结构更为稳定，即： Master <‐ Slave1 <‐ Slave2 <‐ Slave3 .. .

この構造により、単一障害点の問題を解決し、 マスターを スレーブ に置き換えることが容易になります 。マスターがハングアップした場合は、他のすべてを変更せずに、すぐにSlave1 をマスターとして有効にすることができます。

49.Redis はどのような永続化メソッドを提供しますか?

RDB 永続化方式では、指定した時間間隔でデータのスナップショットを作成し、保存できます 。

AOF 永続モードでは、サーバーへの各書き込み操作が記録されます 。 サーバーが再起動すると、これらのコマンドが再実行されて、元のデータが復元されます 。AOF コマンドは、 redis プロトコルを使用して、各書き込み操作をファイルの末尾に追加して保存します 。 Redis は AOFも 実行できます。AOF ファイルのサイズが大きくなりすぎないように、ファイルはバックグラウンドで書き換えられます。

サーバーの実行中にのみデータを存在させたい場合は 、 永続性を使用する必要はありません 。

2 つの永続化メソッドを同時に有効にすることもできます 。 この場合 、 redis が再起動する と、 AOFファイルが最初にロードされて元のデータが復元されます。これは、通常の状況では、AOFファイルによって保存されたデータ セットの方が大きいためです。 RDBファイルのデータセットは完全である必要があります。

最も重要なことは、 RDB永続化メソッド と AOF永続化 メソッドの違いを理解する ことです 。RDB 永続化メソッド から始めましょう。

50.構成の変更は、 Redisを再起動しなくてもリアルタイムで有効になりますか?

インスタンスを実行するには、再起動を行わずにCONFIG SETコマンドを使用して 変更できる 構成オプションが多数あります。 Redis 2.2以降 では、 Redisを再起動せずに、 AOFからRDBのスナップショット永続化またはその他の手段に 切り替える ことができます 。詳細については、「CONFIG GET * 」コマンドを参照してください。

但偶尔重新启动是必须的，如为升级 Redis 程序到新的版本，或者当你需要修改某些目前 CONFIG 命令还不支持的配置参数的时候。

51.Redis集群会有写操作丢失吗？为什么？

Redis 并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

52.查看Redis使用情况及状态信息用什么命令？

info

53.Mongodb熟悉吗，一般部署几台？

一般 mongodb 部署主从、或者 mongodb 分片集群；建议 3 台或 5 台服务器来部署。 MongoDB 分片的基本思想就是将集合切分 成小块。这些块分散到若干片里面，每个片只负责总数据的一部分。 对于客户端来说，无需知道数据被拆分了，也无需 知道服务端哪个分片对应哪些数据。数据在分片之前需要运行一个路由进程，进程名为 mongos 。这个路由器知道所有数据

的存放位置，知道数据和片的对应关系。对客户端来说，它仅知道连接了一个普通的 mongod ，在请求数据的过程中，通过 路由器上的数据和片的对应关系，路由到目标数据所在的片上，如果请求有了回应，路由器将其收集起来回送给客户端。

54.Rabbitmq和kafka有什么区别？

1 ) 在架构模型方面，

RabbitMQ 遵循 AMQP 协议， RabbitMQ 的 broker 由 Exchange,Binding,queue 组成，其中 exchange 和 binding 组成了消息的路由键；客户端 Producer 通过连接 channel 和 server 进行通信， Consumer 从 queue 获取消息进行消费（长连 接， queue 有消息会推送到 consumer 端， consumer 循环从输入流读取数据）。 rabbitMQ 以 broker 为中心；有消息的确认

机制。

Kafka は、コンシューマを中心とした 一般的な MQ 構造、 プロデューサ 、 ブローカ 、 コンシューマ に従います。 メッセージの消費情報は クライアントの コンシューマ に保存されます。 コンシューマは、消費時点に基づいて ブローカ からバッチ でデータを取得します。メッセージ確認メカニズムはありません。

2 ) スループットに関しては、

Kafka は スループットが高く、内部でメッセージのバッチ処理と ゼロコピー メカニズムを使用しています。データの保存と取得はローカル ディスク上で順次バッチ操作です。 複雑さは O( 1 )で、メッセージ処理の効率は非常に優れています。高い。

RabbitMQ は、 スループットの点で kafkaよりわずかに劣ります 。それらの出発点は異なります。rabbitMQ は 、メッセージの信頼性の高い配信をサポートし、トランザクションをサポートしますが、バッチ操作はサポートしません。ストレージの信頼性要件に基づいて、ストレージはメモリまたはハードディスクを使用できます。

3 ) 使いやすさの面では、

RabbitMQ は ミラーキュー をサポートしており、 メインキューに障害が発生すると、ミラー キューが引き継ぎます。

Kafka の ブローカーは、 アクティブ モードとバックアップ モードをサポートします。

4 ) クラスターの負荷分散に関しては、

Kafka は ZooKeeper を使用して クラスター内のブローカーとコンシューマーを管理します。トピックはZooKeeperに登録できます。ZooKeeperの調整メカニズムを通じて、プロデューサーはトピックに対応するブローカー情報を保存し、ランダムまたはポーリングでブローカーに送信でき、プロデューサーを指定できます。セマンティクス.シャーディングに基づいて、メッセージはブローカーの特定のシャードに送信されます。

RabbitMQ の負荷分散には、サポート用に別の ロードバランサーが必要です 。

55.バックアップのカテゴリは何ですか?

システム バックアップ: オペレーティング システム全体をバックアップします。オペレーティング システムが破損した場合、または起動できない場合は、バックアップによって迅速に復元できます。

データのバックアップ: ユーザーのデータ ファイル、アプリケーション ソフトウェア、データベースをバックアップし、これらのデータが失われたり破損したりした場合は、バックアップによって復元することもできます。

56.コールド/ホットバックアップとは何ですか? それぞれの長所と短所は何ですか?

コールド バックアップ: バックアップが必要なファイルは、まず閉じられて使用が停止されてから、バックアップが実行されます。

利点は、シンプルかつ高速で、特定の時点への復元が容易で、保守が容易であることです。

欠点は、特定の時点までしか復元できないことと、バックアップ期間中の通常の使用にはデータが不便であることです。

ホット バックアップ: バックアップの実行時にバックアップ ファイルの通常の使用に影響を与えない方法を指します。

利点は、バックアップ速度が速く、データ使用量に影響を与えないことです。

欠点は、削除を含むすべての操作が同期されることです。

57. 100Gデータベースをバックアップするにはどうすればよいですか?

100 G を超えるライブラリの場合は、 xtranbackup の使用を検討してください 。バックアップ速度は明らかに mysqldumpよりも 高速です。通常、1 週間に 1 回の完全バックアップが実行され、残りは毎日増分バックアップが実行されます。バックアップ時間はビジネスのオフピーク時に行われます。

58.バックアップと復元の失敗にどう対処するか?

まず、リカバリ中にエラーが発生しないように、リカバリ前に十分な準備を行う必要があります。たとえば、バックアップ後の有効性チェック、権限チェック、スペース チェックなどです。 エラーが報告された場合は、エラーのプロンプトに従って対応する調整を行ってください。

59.mysqldumpバックアップの本質、メリット、デメリットは何ですか？

本質: エクスポートされるのは SQL ステートメント ファイルです

利点: どのようなストレージ エンジンであっても、 mysqldump を使用して SQLステートメント を準備できます。

欠点: 速度が遅い 、 インポート中にフォーマットの互換性がない場合がある 、 増分バックアップを直接実行できない 。

60.論理バックアップとは何ですか?

バックアップされるのは、テーブル作成、データベース作成、挿入などの操作によって実行される SQL ステートメント ( DDL DML DCL )です。

中小規模のデータベースに適していますが、効率は比較的低くなります。 一般に、データベースがmysqldump 、 mydumper 、 into 、 outfile (テーブルのエクスポートとインポート) などの通常のサービスを提供するという前提の下で実行されます。

61.物理バックアップとは何ですか?

データベース ファイル dbfile バイナリ ログ my.cnfを直接コピーします。

大規模なデータベース環境に適しており、ストレージ エンジンによって制限されませんが、別の MySQL バージョンに復元することはできません。

62.ストレージエンジンとは何ですか? 最も一般的に使用されているストレージ エンジンは何ですか?

1.率直に言うと、ストレージ エンジンは、運用データ (ストレージ データ、更新方法 、データのクエリなど) を管理する方法およびメカニズムです 。

2. MySqlデータベース にはさまざまなストレージ エンジンが提供されており 、各ストレージ エンジンには異なる利点があります。

3. ユーザーは、さまざまなニーズに応じてデータ テーブルにさまざまなストレージ エンジンを選択したり、独自のストレージ エンジンを作成したりできます。

4. ライブラリ内の異なるテーブルが異なるストレージ エンジンを使用する場合でも、これらは許可されます。

最も一般的に使用されるストレージ エンジンは、 MyISAM と InnoDBです 。

63.mysqlのバイナリログとは何ですか?

バイナリ ログに は、データベース内のすべての変更操作 ( DDL / DML / DCL ) が記録され、 selectやshowなどのステートメントは含まれません。

マスター/スレーブ レプリケーションで使用され、 マスター サーバーはバイナリ ログ内の変更操作を スレーブ サーバーに送信し、スレーブ サーバーはこれらの変更操作を実行し、

同じ変更がマスターサーバーにも行われます。

データ回復操作に使用されます。

バイナリ ログはデフォルトではオフになっていますが、 log-bin = xxx パラメータを使用してオンにできます。

64.Binlogの動作モードは何ですか? それぞれにどのような特徴があり、企業はどのように選んでいるのでしょうか？

1. 行( 行モード ) ;

ログにはデータの各行の変更された形式が記録され、 スレーブ側で 同じデータが変更されます。

2. ステートメント ( ステートメントモード )

変更された各データはメイン データベースマスター の binlog に完全に記録され 、 マスターで実行されたSQLステートメントは スレーブで完全に実行されます。

3.mixed ( ミックスモード )

前の 2 つのモードを組み合わせると、作業中に関数やトリガーを使用するなどの特別な機能要件があり、混合モードを使用するデータ量が比較的高いレベルに達する場合、行レベル 行 モード の代わりにステートメント モードが選択されます 。

65.オンラインでMySQL binlog を正しくクリーンアップするにはどうすればよいですか?

MySQL の binlogログ は、データ内のデータ変更を記録するため、ポイントインタイムおよびロケーションベースのデータのリカバリが容易になります が、ログ ファイルのサイズはますます大きくなり、大量のディスク領域を使用するため、ログ情報の一部は定期的にクリーニングする必要があります。

手動削除:

まず、マスター/スレーブ ライブラリで使用されている binlog ファイル名を確認します。

マスター(スレーブ)のステータスを表示 \ G

削除する前に必ずバックアップを行ってください。指定した時間の前にログを削除します。

「 2017 ‐09‐01 00 : 00 : 00 」より前のマスター ログをパージ し ます 。

指定されたログ ファイルを削除します。

マスターログを 「 mysql-bin .000001 」にパージします 。

自動的に削除:

binlogの有効期限 を設定して システムが自動的にログを削除できるようにし、有効期限を確認して有効期限を設定します。

「 expired_logs_days 」 のような変数を表示します 。

グローバルexpire_logs_days = 30 を設定します 。

66.mysqlのリレーログとは何ですか？

用于主从复制， master 主服务器将自己的二进制日志发送给 slave 从服务器， slave 先保存在自己的中继日志中，然后再 执行自己本地的 relay log 里的 sql 达到数据库更改和 master 保持一致。

默认中继日志没有开启，可以使用 `relay‐log` 参数开启

67.数据库和数据库实例之间的关系是什么？

通常情况下，数据库实例和数据库是一一对应的关系，也就是一个数据库实例对应一个数据库； 但是，在集群环境中存

在多个数据库实例共同使用一个数据库。比如： oracle RAC

68.什么叫mysql事务？

MySQL 事务主要用于处理操作量大，复杂度高的数据。比如说，在人员管理系统中，你删除一个人员，你即需要删除人员 的基本资料，也要删除和该人员相关的信息，如信箱，文章等等，这样，这些数据库操作语句就构成一个事务！一般来 说，事务是必须满足 4 个条（ ACID ）：原子性（ Atomicity ，或称不可分割性）、一致性（ Consistency ）、隔离性

( 分離 、独立性とも呼ばれます)、耐久性 ( 耐久性 )。

69.MySQLパスワードを紛失しました。取得してください。

mysqld_safe ‐‐ スキップ‐グラント‐テーブル & # データベースサービスの開始

mysql ‐ uroot ‐ ppassowrd ‐ e "use mysql;update user set passowrd = PASSWORD('newpassword') ここで

ユーザー = 'root';フラッシュ権限;"

70.非リレーショナル データベースの典型的な製品、機能、アプリケーション シナリオを挙げてください。

1. memecached の 純粋なメモリ

2.redis 永続 キャッシュ

3. mongodb はドキュメント指向です

短期間の対応するクエリ操作が必要な場合、適切なスキーマ定義を備えたデータ ストレージがない場合、またはデータ ストレージのスキーマ変更が頻繁に行われる場合は、引き続き NoSQL を使用する必要があります。

71. MySQLマルチインスタンスとは何ですか?また、 MySQLマルチインスタンスを構成する方法は何ですか?

MySQLマルチインスタンスとは、 同じサーバー上で複数の MySQLサービス を有効にすることです。それらは異なるポートをリッスンし、複数のサービス プロセスを実行します。それらは互いに独立しており、 相互に影響を与えることなくサーバー リソースの節約などに便利です。アーキテクチャの拡張。

複数のインスタンスを構成するには 2 つの方法があります。

1. 1 つのインスタンス、1 つの構成ファイル、異なるポート

2. mysqld_multiツールに基づいて、 同じ構成ファイル (my.cnf) の下で異なるインスタンスを構成します。

72. MySQLのセキュリティを強化するにはどうすればよいですか? 実現可能な具体策を教えてください。

1. データベースで使用されていないデフォルトのユーザーを削除します。

2. 対応する権限を設定します (リモート接続を含む)

3. コマンド ライン インターフェイスではデータベースのパスワードを入力できません。

4. パスワードを定期的に変更し、パスワードの複雑さを強化する

73.MySQL Sleepスレッドが多すぎる問題を解決するにはどうすればよいですか?

1. スリーププロセスを 強制終了し 、PIDを強制終了します。

2. 構成を変更してサービスを再起動します

[mysqld]

wait_timeout = 600

インタラクティブタイムアウト = 30

注: 運用サーバーを簡単に再起動できない場合は、次の方法を使用して問題を解決することもできます。

set global wait_timeout = 600

set global interactive_timeout = 30 ;

74.sort_buffer_size参数作用？如何在线修改生效？

在每个 connection(session) 第一次连接时需要使用到，来提访问性能

set global sort_buffer_size = 2 M

75.MySQL中myisam与innodb的区别?

1. InnoDB 支持事物，而 MyISAM 不支持事物

2. InnoDB 支持行级锁，而 MyISAM 支持表级锁

3. InnoDB 支持 MVCC, 而 MyISAM 不支持

4. InnoDB 支持外键，而 MyISAM 不支持

5. InnoDB は フルテキスト インデックス作成をサポートしませんが、 MyISAM はサポートします。

76.生産ラインでMySQLデータベースの文字セットを調整するにはどうすればよいですか?

1. まずライブラリのテーブル構造をエクスポートします 。 テーブル構造のみをエクスポートし、バッチで置き換えます 。

2. ライブラリ内のすべてのデータをエクスポートします (新しいデータが生成されない場合)。

3. 次に、 set names = xxxxxをグローバルに置き換えます。

4. 元のデータベースとテーブルを削除し、新しいデータベースとテーブルを作成して、データベースとテーブルの作成ステートメントとすべてのデータをインポートします。

77. MySQLで中国語データが文字化けする原理と、それを防ぐ方法について説明してください。

サーバーシステム、データベース、クライアントの文字セットが統一されていないため、文字を統一する必要があります。

78.エンタープライズ本番向けにMySQLを最適化する方法(複数の角度から説明してください)?

1. サーバーのハードウェア リソースとネットワーク帯域幅を改善する

2.mysql サービス設定ファイル を最適化する

3. スロークエリログをオンにして、問題を分析します。

79.運用中にドロップライブラリSQLステートメントが誤って実行されました。完全に復元するにはどうすればよいですか?

1 、停止主从复制，在主库上执行锁表并刷新 binlog 操作，接着恢复之前的全备文件（比如 0 点的全备）

2 、将 0 点时的 binlog 文件与全备到故障期间的 binlog 文件合并导出成 sql 语句

mysqlbinlog – no‐defaults mysql‐bin .000011 mysql‐bin .000012 > bin.sql

3 、将导出的 sql 语句中 drop 语句删除，恢复到数据库中

mysql ‐ uroot ‐ pmysql123 < bin.sql

80.工作中遇到过哪些数据库故障，请描述2个例子？

1 、开发使用 root 用户在从库上写入数据造成主从数据不一致，并且前端没有展示需要修改的内容（仍旧是老数据）

2 、内网测试环境服务器突然断电造成主从同步故障

【服务器架构篇】

81.常见的MySQL架构?

主从机构            主主架构            主主主架构

82.mysql复制基本原理流程

1. 主： binlog 线程 —— 记录下所有改变了数据库数据的语句，放进 master 上的 binlog 中；

2. 从： io 线程 —— 在使用 start slave 之后，负责从 master 上拉取 binlog 内容，放进自己的 relay log 中；

3. 从： sql 执行线程 —— 执行 relay log 中的语句；

83.MySQL复制的线程有几个及之间的关联

MySQL 的复制是基于如下 3 个线程的交互：

1. マスター 上の バイナリログダンプ スレッド。 マスター の バイナリログイベントを スレーブに 送信する役割を果たします 。

2. スレーブ 上の IO スレッドは、 マスター から バイナリログを受信し、それを リレーログ に書き込む責任があります 。

3. スレーブ 上の SQL スレッドは、 リレー ログの読み取り と実行を担当します。

84. mysqlのマスターとスレーブ間のデータの不一致を検出するにはどうすればよいですか? それを修正するにはどうすればよいですか?

1. Percana-Toolkitツール コンポーネントのpt-table-checksum を 使用して 検証できます。

2. 次に、 pt-check-sync を使用し て更新を同期します (実際の状況に応じて使用してください)

85.オンラインMySQLマスター/スレーブ レプリケーションの失敗を解決するにはどうすればよいですか?

データベースからログインする

1. スレーブ停止、マスタ・スレーブ同期停止 の実行

2. 次に、 global sql_slave_skip_counter = 1 を設定し 、1 ステップのエラーをスキップします

3. 最後に start smile を実行し、 マスターとスレーブの同期状態を確認します。

マスタスレーブ同期動作を再実行する手順は以下のとおりです。

メインライブラリーに入る

1. データベースを完全に準備し、 binlog を更新して メイン データベースのステータスを確認します。

2. すべてのバックアップ ファイルをスレーブ データベースに復元し、 変更マスターを実行します。

3. マスタースレーブ同期スタートスレーブを開始し 、 マスター スレーブ同期ステータスを確認します

86.マスター/スレーブ レプリケーションに障害があるかどうかを監視するにはどうすればよいですか? (または、 mysql のマスター/スレーブ レプリケーションのステータスが正常かどうかを監視するためのzabbixのスクリプトのアイデアは何ですか?)

mysql ‐ uroot ‐ ppassowrd ‐ e "スレーブステータスを表示\G" | grep - E

"スレーブ_IO_実行中|スレーブ_SQL_実行中" | awk '{print $2}' | grep -c はい

Yesの数 を判断することで マスター/スレーブ レプリケーションの状態を監視します(通常は 2に相当します)

87. 1 つのマスターと複数のスレーブの生産が停止しています。手動で復元するにはどうすればよいですか?

1. スレーブ停止またはサービス停止 を実行

2. スレーブデータベースを修復する

3. その後、メインデータベースの同期を再実行します。

88. 1 つのマスターと複数のスレーブのマスター データベースの生産が停止しています。手動で復元するにはどうすればよいですか?

1. 各スレーブ データベースにログインして同期を停止し、誰のデータが最新であるかを確認し、それを新しいマスター データベースとして設定し、他のスレーブ データベースにデータを同期させます。

2. マスター データベースを修復した後は、マスターとスレーブの同期手順を実行するだけです。

# 新しいメイン ライブラリが以前は読み取り専用だった場合、書き込み可能にするにはこの機能をオフにする必要があることに注意してください。

# 新しいスレーブ ライブラリには、以前のマスター ライブラリと同じ同期されたユーザーと権限を作成する必要があります

#他の スレーブ ライブラリは、 マスターを master_port = 新しいマスター ライブラリのポートに変更し、 スレーブを開始します。

89.MySQLでレプリケーションが遅延する理由は何ですか? の解き方？

1. 同期する必要があるデータベースのデータが多すぎます。

2. スレーブ ライブラリのハードウェア リソースが不足しているため、改善する必要があります。

3. ネットワークの問題、ネットワーク帯域幅を増やす必要がある

4. メイン データベースには大量のデータが書き込まれており、最適な構成とハードウェア リソースが必要です。

5. SQLステートメントの実行に時間がかかりすぎるため、最適化する必要があります 。

6.5.6より前は シングルスレッド レプリケーションでしたが、6.5.6 以降はマルチスレッドになりました。 バージョン 5.7以降も使用できます。

90.大規模なMySQLクラスター アーキテクチャを企業で運用するための実行可能なバックアップ ソリューションを教えてください。

1. デュアルマスターと複数のスレーブ、マスター/スレーブ同期アーキテクチャ、および特定のスレーブデータベースをバックアップサーバーとして実装

2. サブデータベースとテーブルのバックアップを実装し、スケジュールされたタスクを追加するスクリプトを作成します。

3. 最後に、バックアップ サービスがイントラネットのプロフェッショナル サーバーにプッシュされ、データベース サーバーはローカルに 1 週​​間保持されます。

4. バックアップサーバーは状況に応じてバックアップデータを保持します（通常 30 日間）

91.讲述一下Tomcat8005、8009、8080三个端口的含义？

8005 ‐‐‐‐‐‐‐ 关闭时使用

8009 ‐‐‐‐‐‐‐ 为 AJP 端口，即容器使用，如 Apache 能通过 AJP 协议访问 Tomcat 的 8009 端口

8080 ‐‐‐‐‐‐‐ 一般应用使用

92.Tomcat有三种工作模式：Bio、Nio和Apr，他们工作原理是？

Bio(Blocking I / O) ：默认工作模式，阻塞式 I / O 操作，没有任何优化技术处理，性能比较低。

Nio(New I / O or Non‐Blocking) ：非阻塞式 I / O 操作，有 Bio 有更好的并发处理性能。

Apr (Apache ポータブル ランタイム 、 Apache ポータブル ランタイム ) : 主に複数のオペレーティング システム プラットフォーム間で使用できる下位レベルのサポート インターフェイス ライブラリを上位層のアプリケーションに提供する推奨動作モード。

Tomcat は、 AprベースのTomcat ネイティブライブラリ を使用して オペレーティング システム レベルの制御を実現し、最適化テクノロジとノンブロッキングI / O操作を提供して、同時処理能力を大幅に向上させます。ただし、 aprおよびTomcat ネイティブライブラリをインストールする必要があります。

93. Tomcatで使用されるコネクタについて説明してください。

Tomcat では 、次の 2 種類のコネクタが使用されます。

HTTP コネクタ : 動作方法を決定し、リダイレクトやプロキシ転送などの機能にアクセスするために変更できるプロパティが多数あります。

AJP 连接器 : 它以与 HTTP 连接器相同的方式工作，但是他们使用的是 HTTP 的 AJP 协议。 AJP 连接器通常通过插件技术 mod_jk 在 Tomcat 中实现

94.Tomcat调优大概有哪些思路？

1 、增加最大连接数

2 、调整工作模式

3 、启用 gzip 压缩

4 、调整 JVM 内存大小

5 、与 Apache 或 Nginx 整合，实现动静分离

6 、合理选择垃圾回收算法

7 、尽量使用较新 JDK 版本

95.请写下命令检查nginx的当前配置文件，然后平滑重启

1. 确认 nginx 配置文件的语法是否正确

nginx ‐ t

2. スムーズな再起動

kill ‐ HUP nginx プロセス ID

kill ‐ HUP /path/nginx.pid _ _ _

96. nginxとphp-fpmの2つの接続方法とその長所と短所を簡単に説明してください

Linux では 、 nginx サーバーと php-fpm は tcp ソケットとunix ソケットの2 つの方法で実装 できます 。

Unix ソケットは、 同じオペレーティング システム上の 2 つ以上のプロセス間のデータ通信を可能にする端末です。この方法では、 nginx構成ファイルに php-fpmのpidファイルの場所 を入力する必要がありますが、これは tcpソケットよりも効率的です。

tcpソケット の通信方法には、 nginx 設定ファイルに 動作する php-fpmの IPアドレスとポート番号を記入する必要があります。この方法の利点は、サーバーをまたがることができることです。この方法は、 nginxとphp-fpm が同じマシン上にない場合にのみ使用できます。

97.よく使われるNginxモジュールは何に使われますか?

書き換え機能を実装するrewriteモジュール

アクセス モジュール: ソース管理

ssl モジュール: 安全な暗号化

ngx_http_gzip_module : ネットワーク伝送圧縮モジュール

ngx_http_proxy_module モジュールはプロキシを実装します

ngx_http_upstream_module モジュール実装はバックエンド サーバー リストを定義します

ngx_cache_purge は キャッシュクリア機能を実装します

98. Nginxがサポートする負荷分散モードと各モードのアプリケーション シナリオを指摘します。

1.リクエストを各バックグラウンド サーバーに順番に分散する ラウンドロビン ポーリング方式が、デフォルトの負荷分散方式です。バックグラウンド マシンのパフォーマンスが安定している 状況。壊れたマシンはサービス リストから自動的に削除されます。

2. 重み付けは、 重み付けに基づいてリクエストをさまざまなマシンに分散します。これは、バックグラウンド マシンのパフォーマンスが異なる状況に適しています。

3. ip_hash は、 リクエスターの IP の ハッシュ値に基づいて リクエストをバックエンド サーバーに送信します。これにより、同じ IPからのリクエストが 固定マシンに送信されることが保証され、 セッションの 問題を解決できます。

4. url_hash は、 リクエストされた URL の ハッシュ値に基づいて リクエストを異なるマシンに分割し、バックエンド サーバーがキャッシュされている場合に非常に効率的です。

5. Fair は 、バックグラウンドの応答時間に基づいてリクエストを分散します。応答時間が短いほど、より多くのリクエストが分散されます。

99. Keepalivedの動作原理について教えてください。

仮想ルータでは、常に MASTER である VRRPルータのみが VRRP広告情報を 送信し 、BACKUP は優先度が高くない限りMASTER をプリエンプトしません。MASTERが使用できない（BACKUP が通知情報を受信できない）場合、複数のBACKUPの中で最も優先度の高い BACKUPがMASTERとしてプリエンプトされます。このプリエンプションは非常に高速( < 1秒)でサービスの継続性を確保します。セキュリティ上の考慮事項により、VRRPパケットは暗号化プロトコルを使用して暗号化されます。BACKUP は通知情報を、通知情報を受信するだけです。

100. keepalivedの主なモジュールは何ですか?

keepalived に は主に core 、 check 、 vrrpという 3 つのモジュールがあります 。

コア モジュールは keepalivedの中核であり 、メイン プロセスの起動とメンテナンス、およびグローバル設定ファイルのロードと解析を担当します。

check は 、さまざまな一般的な検査方法を含む健康検査を担当します。

VRRPモジュールは VRRPプロトコル を実装するために使用されます。

101. keepalived はどのようにヘルスチェックを実行しますか?

キープアライブ ヘルスチェックモードの設定

HTTP_GET | SSL_GET

HTTP_GET | SSL_GET

{

URL {

path / # HTTP/SSL チェック URL は 複数指定可能

Digest < STRING > # HTTP/SSL検査 後のダイジェスト情報は、 genhashツールを使用して 生成されます

status_code 200 # HTTP/SSL チェックによって返されたステータス コード

}

connect_port 80 #接続 ポート

<IPADD> にバインド します

connect_timeout 3 # 连接超时时间

nb_get_retry 3 # 重连次数

delay_before_retry 2 # 连接间隔时间

}

102.Keepalived怎么实现高可用？

Keepalived 高可用服务对之间的故障切换转移，是通过 VRRP 协议来实现的。

在 Keepalived 服务正常工作时，主 Master 节点会不断地向备节点发送（多播的方式）心跳消息，用以告诉备 Backup 节点自己还活看，当主 Master 节点发生故障时，就无法发送心跳消息，备节点也就因此无法继续检测到来自主 Master 节 点的心跳了，于是调用自身的接管程序，接管主 Master 节点的 IP 资源及服务。而当主 Master 节点恢复时，备 Backup 节 点又会释放主节点故障时自身接管的 IP 资源及服务，恢复到原来的备用角色。

103.Linuxクラスターの主なタイプは何ですか?

1.LB ロード バランシングクラスタ

負荷分散クラスターの主な目的は、サービスの応答性を向上させることです。コンピューター ノードのグループ (またはプロセスのグループ) が同じ (同種の) サービスを提供する場合、サービスへの要求はこれらのノードに均等に分散される必要があります。ソフトウェア レベルで最も一般的な 2 つは、 LVS と Haproxy です。

2. HA 高可用性クラスター

高可用性クラスターは、主に 7 時間 24 時間中断のないサービスを提供し 、 特定のコンピューターがダウンした場合 、 自動的に他のコンピューターに切り替えて稼働することで 、 高可用性を実現します。 一般的なHA 高可用性クラスター ソリューションには次のものがあります: heartbeat 、 corosync + openais RHCS 、 Ultramokey 、 keepalived

3. HP 高性能クラスター

高性能クラスターは主に、 天気予報、海外の3D大ヒット作の特殊効果制作、大量のコンピューティングを必要とする一連のアプリケーションなど、大量の CPU コンピューティングを必要とするシナリオで使用されます 。一般的な HP 高性能クラスター ソリューションには次のものがあります 。 お辞儀する

104.いくつかの一般的な負荷分散方法の比較?

1.LVS の 特徴

1. ネットワークの第 4層 で動作し、耐負荷性が高く、配信に使用されます。

2. 構成可能性が比較的低い。

3. 安定して動作し、独自のデュアルマシンホットバックアップソリューションを備えています。

4. 幅広いアプリケーションがあり、すべてのアプリケーションの負荷分散が可能です。

2.NGINX の 特徴

1.ネットワークのレイヤー 7で 動作します 。

2. ネットワークへの依存度が比較的小さい。

3. インストールと構成が比較的簡単で、テストがより便利です。

4. 高負荷圧力に耐えることができ、安定しています。

5. 内部サーバーの障害はポートを通じて検出できます。

6. リクエストの非同期処理は、ノード サーバーの負荷を軽減するのに役立ちます。

7. httpと電子メール をサポートできます 。

8.デフォルトでは、 負荷分散アルゴリズムはラウンドロビンとIP ハッシュの2 つ だけです。

3. Haproxy の特徴

1. ネットワーク層 7より上で動作します 。

2. セッションの維持、Cookieガイダンスなど、Nginxのいくつかの欠点 を補うことができます。

3. URL検出バックエンドサーバーの問題検出を サポート

4. さらなる負荷分散戦略

5. ロードバランシング速度の向上

6. HAProxy はMysql の負荷分散を行い、 バック エンドDBノードを検出して負荷分散することができます。

105.lvsスケジューリング アルゴリズムにおける最小接続数アルゴリズムの原理は何ですか?

最少连接调度算法是把新的连接请求分配到当前连接数最小的服务器，最小连接调度是一种动态调度短算法，它通过服务器当前所活跃的连接数来估计服务器 的负载均衡，调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到 某台服务器，其连接数加1，当连接中止或超时，其连接数减一，在系统实现时， 我们也引入当服务器的权值为0时，表示该服务器不可用而不被调度。

106.简单介绍lvs的三种工作模型

1 、 NAT 模型

NAT 模型是通过网络地址转换来实现的 , 工作方式是 , 首先用户请求到达前端的负载均衡器，然后负载均衡器根据事先定义好的调度算法将用户请求的目标地址修改为后端的应用服务器，应用程序服务器处理好请求之后将结果返回给用户 , 期间 必须要经过负载均衡器 , 负载均衡器将报文的源地址 改为用户请求的目标地址 , 再转发给用户 , 从而完成整个负载均衡的过 程 ,

2 、 DR 模型

DR 模型是通过路由技术实现的负载均衡技术 , 这种模型与 NAT 模型不同的地方是 , 负载均衡器通过改写用户请求报文中的 MAC 地址 , 将请求发送到 Real Server, 而 Real Server 直接响应用户 , 这样就大大的减少负载均衡器的压力 ,DR 模型也是 用的最多的一种。

3 、 TUN 模型

TUN 模型是通过 IP 隧道技术实现的 ,TUN 模型跟 DR 模型有点类似 , 不同的地方是负载均衡器 (Director Server) 跟应用服务器 (Real Server) 通信的机制是通过 IP 隧道技术将用户的请求转发到某个 Real Server, 而 Real Server 也是直接响应 用户的

107.集群中资源隔离的解决方案？

1 、当集群分裂成两个小集群时会发生资源争用的情况，为避免争用后端存储系统而造成灾难性的系统崩溃，集群系统引

入了投票机制，只有拥有半数以上合法票数的集群才能存活，否则就推出集群系统。

2 、当集群为偶数时，如果分裂，两边可能都掌握相等的票数；因此，集群系统不应该为偶数，如果是偶数则需要一个额

外的 ping 节点参与投票。

3 、票数不足的集群退出集群服务后，为了保证它不会争用资源需要 STONITH 机制来进行资源隔离。