2.Nginx优化

时间  2020-06-29
标签 2.nginx nginx 优化 栏目 Nginx 繁體版
原文   原文链接

【教程主题】：Nginx优化javascript

【课程录制】： 创Ephp

【主要内容】css

Nginx 优化html

nginx介绍java

Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,Nginx，它的发音为“engine X”，是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP 代理服务器．Nginx是由俄罗斯人 Igor Sysoev为俄罗斯访问量第二的 Rambler.ru站点开发.node

Nginx以事件驱动（epoll）的方式编写，因此有很是好的性能，同时也是一个很是高效的反向代理、负载平衡。其拥有匹配 Lighttpd的性能，同时尚未Lighttpd的内存泄漏问题，并且Lighttpd的mod_proxy也有一些问题而且好久没有更新。可是Nginx并不支持cgi方式运行，缘由是能够减小所以带来的一些程序上的漏洞。因此必须使用FastCGI方式来执行PHP程序。linux

nginx作为HTTP服务器，有如下几项基本特性：nginx

处理静态文件，索引文件以及自动索引；打开文件描述符缓冲．web

无缓存的反向代理加速，简单的负载均衡和容错．apache

FastCGI，简单的负载均衡和容错．

模块化的结构。包括gzipping, byte ranges, chunked responses,以及 SSI-filter等filter。若是由FastCGI或其它代理服务器处理单页中存在的多个SSI，则这项处理能够并行运行，而不须要相互等待。

Nginx专为性能优化而开发，性能是其最重要的考量,实现上很是注重效率。它支持内核ePoll模型，能经受高负载的考验,有报告代表能支持高达 50,000个并发链接数。

Nginx具备很高的稳定性。其它HTTP服务器，当遇到访问的峰值，或者有人恶意发起慢速链接时，也极可能会致使服务器物理内存耗尽频繁交换，失去响应，只能重启服务器。例如当前apache一旦上到200个以上进程，web响应速度就明显很是缓慢了。而Nginx采起了分阶段资源分配技术，使得它的CPU与内存占用率很是低。nginx官方表示保持10,000个没有活动的链接，它只占2.5M内存，因此相似DOS这样的攻击对nginx来讲基本上是毫无用处的。就稳定性而言,nginx比lighthttpd更胜一筹。

Nginx支持热部署。它的启动特别容易, 而且几乎能够作到7*24不间断运行，即便运行数个月也不须要从新启动。你还可以在不间断服务的状况下，对软件版本进行进行升级。

ab的使用

[root@localhost bin]# ab -n 10 -c 10 http://opslinux.com/

意思是这样的：

-n表示发送多少个请求，

-c表示一次发送多少个（实际上就是把-n分批发送），

后面跟地址，注意后的斜杠。

返回信息以下（红色部分为个人注释）：

This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking http://www.yi1.com.cm/ (be patient)…..done
Server Software:        Apache/2.2.4
Server Hostname:        http://opslinux.com/
Server Port:            80

Document Path:          /
Document Length:        31848 bytes

Concurrency Level:      10
Time taken for tests:   1.722254 seconds/*测试持续时间*/
Complete requests:      10/*完成请求数量*/
Failed requests:        0/*失败请求数量*/
Write errors:           0
Total transferred:      323490 bytes/*总流量*/
HTML transferred:       318480 bytes/*HTML传输量*/
Requests per second:    5.81 [#/sec] (mean)/*每秒事务数*/
Time per request:       1722.254 [ms] (mean)/*平均响应时间*/
Time per request:       172.225 [ms] (mean, across all concurrent requests)/*每一个请求响应时间（平均）*/
Transfer rate:          182.90 [Kbytes/sec] received/*传输效率*/

Connection Times (ms)
min  mean[+/-sd] median   max
Connect:      165  166   1.2    167     168
Processing:  1300 1418  91.5   1427    1554
Waiting:      803  925  92.9    929    1064
Total:       1465 1585  92.2   1595    1721

Percentage of the requests served within a certain time (ms)
50%   1595/*50%的请求响应时间小于1595*/
66%   1620/*66%的请求响应时间小于1620*/
75%   1668
80%   1706
90%   1721
95%   1721
98%   1721
99%   1721
100%   1721 (longest request)/*最长响应时间1721*/

 

编译安装过程优化

在编译Nginx时，默认以debug模式进行，而在debug模式下会插入不少跟踪和ASSERT之类的信息，编译完成后，一个Nginx要有好几兆字节。在编译前取消Nginx的debug模式，编译完成后Nginx只有几百千字节，所以能够在编译以前，修改相关源码，取消debug模式，具体方法以下： 在Nginx源码文件被解压后，找到源码目录下的auto/cc/gcc文件，在其中找到以下几行:

# debug

CFLAGS=”$CFLAGS -g”

注释掉或删除

为特定的CPU指定CPU类型编译优化

在编译Nginx时，默认的GCC编译参数是“-O”，要优化GCC编译，可使用如下两个参数:

--with-cc-opt='-O3'

--with-cpu-opt=CPU  #为特定的 CPU 编译，有效的值包括：pentium, pentiumpro, pentium3, pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64

要肯定CPU类型，能够经过以下命令:

[root@localhost home]#cat /proc/cpuinfo | grep "model name"

利用TCMalloc优化Nginx的性能

TCMalloc的全称为Thread-Caching Malloc，是谷歌开发的开源工具“google-perftools”中的一个成员。与标准的glibc库的malloc相比，TCMalloc库在内存分配效率和速度上要高不少，这在很大程度上提升了服务器在高并发状况下的性能，从而下降系统负载。下面简单介绍如何为Nginx添加TCMalloc库支持。 要安装TCMalloc库，须要安装libunwind（32位操做系统不须要安装）和google-perftools两个软件包，libunwind库为基于64位CPU和操做系统的程序提供了基本函数调用链和函数调用寄存器功能。下面介绍利用TCMalloc优化Nginx的具体操做过程：

1.安装libunwind库

能够从http://download.savannah.gnu.org/releases/libunwind下载相应的libunwind版本，这里下载的是libunwind-0.99-alpha.tar.gz，安装过程以下

[root@localhost home]#tar zxvf libunwind-0.99-alpha.tar.gz

[root@localhost home]# cd libunwind-0.99-alpha/

[root@localhost libunwind-0.99-alpha]#CFLAGS=-fPIC ./configure

[root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC

[root@localhost libunwind-0.99-alpha]#make CFLAGS=-fPIC install

2.安装google-perftools

能够从http://google-perftools.googlecode.com下载相应的google-perftools版本，这里下载的是google-perftools-1.8.tar.gz，安装过程以下:

[root@localhost home]# tar zxvf google-perftools-1.8.tar.gz

[root@localhost home]# cd google-perftools-1.8/

[root@localhost google-perftools-1.8]# ./configure

[root@localhost google-perftools-1.8]# make && make install

[root@localhost google-perftools-1.8]# echo "/usr/local/lib" > /etc/ld.so.conf.d/usr_local_lib.conf

[root@localhost google-perftools-1.8]# ldconfig

至此，google-perftools安装完成。

3.从新编译Nginx

为了使Nginx支持google-perftools，须要在安装过程当中添加“–with-google_perftools_module”选项从新编译Nginx，安装代码以下:

[root@localhostnginx-0.7.65]#

./configure --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_gzip_static_module --with-ipv6 --with-google_perftools_module

 

[root@localhost nginx-0.7.65]#make

[root@localhost nginx-0.7.65]#make install

到这里Nginx安装完成。

4.为google-perftools添加线程目录

建立一个线程目录，这里将文件放在/tmp/tcmalloc下，操做以下:

[root@localhost home]#mkdir /tmp/tcmalloc

[root@localhost home]#chmod 0777 /tmp/tcmalloc

5.修改Nginx主配置文件

修改nginx.conf文件，在pid这行的下面添加以下代码:

#pid        logs/nginx.pid;

google_perftools_profiles /tmp/tcmalloc;

接着，重启Nginx，完成google-perftools的加载。

6.验证运行状态

为了验证google-perftools已经正常加载，经过以下命令查看:

[root@ localhost home]# lsof -n | grep tcmalloc

nginx      2395 nobody   9w  REG    8,8       0    1599440 /tmp/tcmalloc.2395

nginx      2396 nobody   11w REG   8,8       0    1599443 /tmp/tcmalloc.2396

nginx      2397 nobody   13w REG  8,8        0    1599441  /tmp/tcmalloc.2397

nginx     2398 nobody    15w REG  8,8     0    1599442 /tmp/tcmalloc.2398

因为在Nginx配置文件中，设置worker_processes的值为4，所以开启了4个Nginx线程，每一个线程会有一行记录。每一个线程文件后面的数字值就是启动的Nginx的PID值。 至此，利用TCMalloc优化Nginx的操做完成。

Nginx内核参数优化

内核参数的优化，主要是在Linux系统中针对Nginx应用而进行的系统内核参数优化，常见的优化参数值以下。

下面给出一个优化实例以供参考:

net.ipv4.tcp_max_tw_buckets = 6000

net.ipv4.ip_local_port_range = 1024 65000

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_syncookies = 1

net.core.somaxconn = 262144

net.core.netdev_max_backlog = 262144

net.ipv4.tcp_max_orphans = 262144

net.ipv4.tcp_max_syn_backlog = 262144

net.ipv4.tcp_synack_retries = 1

net.ipv4.tcp_syn_retries = 1

net.ipv4.tcp_fin_timeout = 1

net.ipv4.tcp_keepalive_time = 30

将上面的内核参数值加入/etc/sysctl.conf文件中，而后执行以下命令使之生效:

[root@ localhost home]#/sbin/sysctl -p

下面是对实例中选项的含义进行介绍：

net.ipv4.tcp_max_tw_buckets参数用来设定timewait的数量，默认是180000，这里设为6000。

net.ipv4.ip_local_port_range选项用来设定容许系统打开的端口范围。

net.ipv4.tcp_tw_recycle选项用于设置启用timewait快速回收。

net.ipv4.tcp_tw_reuse选项用于设置开启重用，容许将TIME-WAIT sockets从新用于新的TCP链接。

net.ipv4.tcp_syncookies选项用于设置开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies进行处理。

net.core.somaxconn选项默认值是128， 这个参数用于调节系统同时发起的tcp链接数，在高并发的请求中，默认的值可能会致使连接超时或者重传，所以，须要结合并发请求数来调节此值。

net.core.netdev_max_backlog选项表示当每一个网络接口接收数据包的速率比内核处理这些包的速率快时，容许发送到队列的数据包的最大数目。

net.ipv4.tcp_max_orphans选项用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。若是超过这个数字，孤立链接将当即被复位并打印出警告信息。这个限制只是为了防止简单的DoS攻击。不能过度依靠这个限制甚至人为减少这个值，更多的状况是增长这个值。

net.ipv4.tcp_max_syn_backlog选项用于记录那些还没有收到客户端确认信息的链接请求的最大值。对于有128MB内存的系统而言，此参数的默认值是1024，对小内存的系统则是128。

net.ipv4.tcp_synack_retries参数的值决定了内核放弃链接以前发送SYN+ACK包的数量。

net.ipv4.tcp_syn_retries选项表示在内核放弃创建链接以前发送SYN包的数量。

net.ipv4.tcp_fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。默认值是60秒。正确设置这个值很是重要，有时候即便一个负载很小的Web服务器，也会出现由于大量的死套接字而产生内存溢出的风险。

net.ipv4.tcp_keepalive_time选项表示当keepalive启用的时候，TCP发送keepalive消息的频度。默认值是2（单位是小时）。

下面贴一个完整的内核优化设置:

vi /etc/sysctl.conf CentOS5.5中能够将全部内容清空直接替换为以下内容:

net.ipv4.ip_forward = 0

net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.default.accept_source_route = 0

kernel.sysrq = 0

kernel.core_uses_pid = 1

net.ipv4.tcp_syncookies = 1

kernel.msgmnb = 65536

kernel.msgmax = 65536

kernel.shmmax = 68719476736

kernel.shmall = 4294967296

net.ipv4.tcp_max_tw_buckets = 6000

net.ipv4.tcp_sack = 1

net.ipv4.tcp_window_scaling = 1

net.ipv4.tcp_rmem = 4096 87380 4194304

net.ipv4.tcp_wmem = 4096 16384 4194304

net.core.wmem_default = 8388608

net.core.rmem_default = 8388608

net.core.rmem_max = 16777216

net.core.wmem_max = 16777216

net.core.netdev_max_backlog = 262144

net.core.somaxconn = 262144

net.ipv4.tcp_max_orphans = 3276800

net.ipv4.tcp_max_syn_backlog = 262144

net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_synack_retries = 1

net.ipv4.tcp_syn_retries = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_mem = 94500000 915000000 927000000

net.ipv4.tcp_fin_timeout = 1

net.ipv4.tcp_keepalive_time = 30

net.ipv4.ip_local_port_range = 1024 65000

配置文件优化

基本优化

通常来讲nginx 配置文件中对优化比较有做用的为如下几项：

  1. worker_processes 8;

nginx 进程数，建议按照cpu 数目来指定，通常为它的倍数 (如,2个四核的cpu计为8)。

  1. worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

为每一个进程分配cpu，上例中将8 个进程分配到8 个cpu，固然能够写多个，或者将一 个进程分配到多个cpu。

  1. worker_rlimit_nofile 65535;

这个指令是指当一个nginx 进程打开的最多文件描述符数目，理论值应该是最多打开文 件数（ulimit -n）与nginx 进程数相除，可是nginx 分配请求并非那么均匀，因此最好与ulimit -n 的值保持一致。详见ulimit关于系统链接数的优化

如今在linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。

这是由于nginx调度时分配请求到进程并非那么的均衡，因此假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。

查看linux系统文件描述符的方法:

[root@web001 ~]# sysctl -a | grep fs.file

 

fs.file-max = 789972

 

fs.file-nr = 510 0 789972

  1. use epoll;

使用epoll 的I/O 模型

(

补充说明:

与apache相类，nginx针对不一样的操做系统，有不一样的事件模型

A）标准事件模型 Select、poll属于标准事件模型，若是当前系统不存在更有效的方法，nginx会选择select或poll B）高效事件模型 Kqueue：使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用双处理器的MacOS X系统使用kqueue可能会形成内核崩溃。 Epoll: 使用于Linux内核2.6版本及之后的系统。

/dev/poll：使用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。

Eventport：使用于 Solaris 10. 为了防止出现内核崩溃的问题， 有必要安装安全补丁。

)

  1. worker_connections 65535;

每一个进程容许的最多链接数， 理论上每台nginx 服务器的最大链接数为worker_processes*worker_connections。

  1. keepalive_timeout 60;

keepalive 超时时间。

  1. client_header_buffer_size 4k;

客户端请求头部的缓冲区大小，这个能够根据你的系统分页大小来设置，通常一个请求头的大小不会超过1k，不过因为通常系统分页都要大于1k，因此这里设置为分页大小。

分页大小能够用命令getconf PAGESIZE 取得。

[root@web001 ~]# getconf PAGESIZE

4096

但也有client_header_buffer_size超过4k的状况，可是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。

  1. open_file_cache max=65535 inactive=60s;

这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指通过多长时间文件没被请求后删除缓存。

  1. open_file_cache_valid 80s;

这个是指多长时间检查一次缓存的有效信息。

  1. open_file_cache_min_uses 1;

open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，若是超过这个数字，文件描述符一直是在缓存中打开的，如上例，若是有一个文件在inactive 时间内一次没被使用，它将被移除。

简单配置文件

下面是一个简单的nginx 配置文件:

user www www;

worker_processes 8;

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000

01000000;

error_log /www/log/nginx_error.log crit;

pid /usr/local/nginx/nginx.pid;

worker_rlimit_nofile 204800;

events

{

use epoll;

worker_connections 204800;

}

http

{

include mime.types;

default_type application/octet-stream;

charset utf-8;

server_names_hash_bucket_size 128;

client_header_buffer_size 2k;

large_client_header_buffers 4 4k;

client_max_body_size 8m;

sendfile on;

tcp_nopush on;

keepalive_timeout 60;

fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2

keys_zone=TEST:10m

inactive=5m;

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

fastcgi_buffer_size 4k;

fastcgi_buffers 8 4k;

fastcgi_busy_buffers_size 8k;

fastcgi_temp_file_write_size 8k;

fastcgi_cache TEST;

fastcgi_cache_valid 200 302 1h;

fastcgi_cache_valid 301 1d;

fastcgi_cache_valid any 1m;

fastcgi_cache_min_uses 1;

fastcgi_cache_use_stale error timeout invalid_header http_500;

open_file_cache max=204800 inactive=20s;

open_file_cache_min_uses 1;

open_file_cache_valid 30s;

tcp_nodelay on;

gzip on;

gzip_min_length 1k;

gzip_buffers 4 16k;

gzip_http_version 1.0;

gzip_comp_level 2;

gzip_types text/plain application/x-javascript text/css application/xml;

gzip_vary on;

server

{

listen 8080;

server_name backup.aiju.com;

index index.php index.htm;

root /www/html/;

location /status

{

stub_status on;

}

location ~ .*\.(php|php5)?$

{

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fcgi.conf;

}

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$

{

expires 30d;

}

log_format access ‘$remote_addr — $remote_user [$time_local] “$request” ‘

‘$status $body_bytes_sent “$http_referer” ‘

‘”$http_user_agent” $http_x_forwarded_for’;

access_log /www/log/access.log access;

}

}

关于FastCGI 的几个指令：

fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10minactive=5m;

这个指令为FastCGI 缓存指定一个路径，目录结构等级，关键字区域存储时间和非活动删除时间。

fastcgi_connect_timeout 300;

指定链接到后端FastCGI 的超时时间。

fastcgi_send_timeout 300;

向FastCGI 传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI 传送请求的超时时间。

fastcgi_read_timeout 300;

接收FastCGI 应答的超时时间，这个值是指已经完成两次握手后接收FastCGI 应答的超时时间。

fastcgi_buffer_size 4k;

指定读取FastCGI 应答第一部分须要用多大的缓冲区，通常第一部分应答不会超过1k，因为页面大小为4k，因此这里设置为4k。

fastcgi_buffers 8 4k;

指定本地须要用多少和多大的缓冲区来缓冲FastCGI 的应答。

fastcgi_busy_buffers_size 8k;

这个指令我也不知道是作什么用，只知道默认值是fastcgi_buffers 的两倍。

fastcgi_temp_file_write_size 8k;

在写入fastcgi_temp_path 时将用多大的数据块，默认值是fastcgi_buffers 的两倍。

fastcgi_cache TEST

开启FastCGI 缓存而且为其制定一个名称。我的感受开启缓存很是有用，能够有效下降CPU 负载，而且防止502 错误。

fastcgi_cache_valid 200 302 1h; fastcgi_cache_valid 301 1d; fastcgi_cache_valid any 1m;

为指定的应答代码指定缓存时间，如上例中将200，302 应答缓存一小时，301 应答缓存1 天，其余为1 分钟。

fastcgi_cache_min_uses 1;

缓存在fastcgi_cache_path 指令inactive 参数值时间内的最少使用次数，如上例，若是在5 分钟内某文件1 次也没有被使用，那么这个文件将被移除。

fastcgi_cache_use_stale error timeout invalid_header http_500;

不知道这个参数的做用，猜测应该是让nginx 知道哪些类型的缓存是没用的。以上为nginx 中FastCGI 相关参数，另外，FastCGI 自身也有一些配置须要进行优化，若是你使用php-fpm 来管理FastCGI，能够修改配置文件中的如下值：

再来优化PHP-FPM，打开/usr/local/php/etc/php-fpm.conf，这个文件和PHP的语法很类似，凡是须要激活的配置，直接删掉前面的分号（;）便可：

  1. [global]  
  3. pid = run/php-fpm.pid  
  5. process_control_timeout=5  
  7. [www]  
  9. listen.allowed_clients = 127.0.0.1  
  11. user=www-data  
  13. group=www-data  
  15. pm=dynamic  
  17. pm.max_children=20（这个配置决定了php-fpm的总进程数，内存小的少设点）  
  19. pm.max_requests=10000（并发数越大，此请求数应越大）  
  21. pm.start_servers =10（初始php-fpm进程数）  
  23. emergency_restart_threshold = 60  
  25. emergency_restart_interval = 60s  

上边这两个，表示在emergency_restart_interval所设值内出现SIGSEGV或者SIGBUS错误的php-cgi进程数若是超过 emergency_restart_threshold个，php-fpm就会优雅重启。这两个选项通常保持默认值

 

ulimit关于系统链接数的优化

linux 默认值 open files 和 max user processes 为 1024

#ulimit -n

1024

#ulimit –u

1024

问题描述： 说明 server 只容许同时打开 1024 个文件，处理 1024 个用户进程

使用ulimit -a 能够查看当前系统的全部限制值，使用ulimit -n 能够查看当前的最大打开文件数。

新装的linux 默认只有1024 ，看成负载较大的服务器时，很容易遇到error: too many open files 。所以，须要将其改大。

解决方法：

使用 ulimit –n 65535 可即时修改，但重启后就无效了。（注ulimit -SHn 65535 等效 ulimit -n 65535 ，-S 指soft ，-H 指hard)

修改方式

有以下三种修改方式：

  1. 在/etc/rc.local 中增长一行 ulimit -SHn 65535
  2. 在/etc/profile 中增长一行 ulimit -SHn 65535
  3. 在/etc/security/limits.conf 最后增长:
  4. * soft nofile 65535
  5. * hard nofile 65535
  6. * soft nproc 65535
  7. * hard nproc 65535

具体使用哪一种，在 CentOS 中使用第1 种方式无效果，使用第3 种方式有效果，而在Debian 中使用第2 种有效果

# ulimit -n

65535

# ulimit -u

65535

备注：ulimit 命令自己就有分软硬设置，加-H 就是硬，加-S 就是软默认显示的是软限制

soft 限制指的是当前系统生效的设置值。 hard 限制值能够被普通用户下降。可是不能增长。 soft 限制不能设置的比 hard 限制更高。 只有 root 用户才可以增长 hard 限制值。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程