|
#
Linux is a powerhouse when it comes to networking, and provides a full featured and high performance network stack. When combined with web front-ends such asHAProxy, lighttpd, Nginx, Apache or your favorite application server, Linux is a killer platform for hosting web applications. Keeping these applications up and operational can sometimes be a challenge, especially in this age of horizontally scaled infrastructure and commodity hardware. But don't fret, since there are a number of technologies that can assist with making your applications and network infrastructure fault tolerant. One of these technologies, keepalived, provides interface failover and the ability to perform application-layer health checks. When these capabilities are combined with the Linux Virtual Server (LVS) project, a fault in an application will be detected by keepalived, and the virtual interfaces that are accessed by clients can be migrated to another available node. This article will provide an introduction to keepalived, and will show how to configure interface failover between two or more nodes. Additionally, the article will show how to debug problems with keepalived and VRRP. What Is Keepalived?
The keepalived project provides a keepalive facility for Linux servers. This keepalive facility consists of a VRRP implementation to manage virtual routers (aka virtual interfaces), and a health check facility to determine if a service (web server, samba server, etc.) is up and operational. If a service fails a configurable number of health checks, keepalived will fail a virtual router over to a secondary node. While useful in its own right, keepalived really shines when combined with the Linux Virtual Server project. This article will focus on keepalived, and a future article will show how to integrate the two to create a fault tolerant load-balancer. Installing KeepAlived From Source Code
Before we dive into configuring keepalived, we need to install it. Keepalived is distributed as source code, and is available in several package repositories. To install from source code, you can execute wget or curl to retrieve the source, and then run "configure", "make" and "make install" compile and install the software: $ wget http://www.keepalived.org/software/keepalived-1.1.17.tar.gz $ tar xfvz keepalived-1.1.17.tar.gz $ cd keepalived-1.1.17 $ ./configure --prefix=/usr/local $ make && make install In the example above, the keepalived daemon will be compiled and installed as /usr/local/sbin/keepalived. Configuring KeepAlived
The keepalived daemon is configured through a text configuration file, typically named keepalived.conf. This file contains one or more configuration stanzas, which control notification settings, the virtual interfaces to manage, and the health checks to use to test the services that rely on the virtual interfaces. Here is a sample annotated configuration that defines two virtual IP addresses to manage, and the individuals to contact when a state transition or fault occurs: # Define global configuration directives global_defs { # Send an e-mail to each of the following # addresses when a failure occurs notification_email { matty@prefetch.net operations@prefetch.net } # The address to use in the From: header notification_email_from root@VRRP-director1.prefetch.net # The SMTP server to route mail through smtp_server mail.prefetch.net # How long to wait for the mail server to respond smtp_connect_timeout 30 # A descriptive name describing the router router_id VRRP-director1 } # Create a VRRP instance VRRP_instance VRRP_ROUTER1 { # The initial state to transition to. This option isn't # really all that valuable, since an election will occur # and the host with the highest priority will become # the master. The priority is controlled with the priority # configuration directive. state MASTER # The interface keepalived will manage interface br0 # The virtual router id number to assign the routers to virtual_router_id 100 # The priority to assign to this device. This controls # who will become the MASTER and BACKUP for a given # VRRP instance. priority 100 # How many seconds to wait until a gratuitous arp is sent garp_master_delay 2 # How often to send out VRRP advertisements advert_int 1 # Execute a notification script when a host transitions to # MASTER or BACKUP, or when a fault occurs. The arguments # passed to the script are: # $1 - "GROUP"|"INSTANCE" # $2 = name of group or instance # $3 = target state of transition # Sample: VRRP-notification.sh VRRP_ROUTER1 BACKUP 100 notify "/usr/local/bin/VRRP-notification.sh" # Send an SMTP alert during a state transition smtp_alert # Authenticate the remote endpoints via a simple # username/password combination authentication { auth_type PASS auth_pass 192837465 } # The virtual IP addresses to float between nodes. The # label statement can be used to bring an interface # online to represent the virtual IP. virtual_ipaddress { 192.168.1.100 label br0:100 192.168.1.101 label br0:101 } } The configuration file listed above is self explanatory, so I won't go over each directive in detail. I will point out a couple of items: - Each host is referred to as a director in the documentation, and each director can be responsible for one or more VRRP instances
- Each director will need its own copy of the configuration file, and the router_id, priority, etc. should be adjusted to reflect the nodes name and priority relative to other nodes
- To force a specific node to master a virtual address, make sure the director's priority is higher than the other virtual routers
- If you have multiple VRRP instances that need to failover together, you will need to add each instance to a VRRP_sync_group
- The notification script can be used to generate custom syslog messages, or to invoke some custom logic (e.g., restart an app) when a state transition or fault occurs
- The keepalived package comes with numerous configuration examples, which show how to configure numerous aspects of the server
Starting Keepalived
Keepalived can be executed from an RC script, or started from the command line. The following example will start keepalived using the configuration file /usr/local/etc/keepalived.conf: $ keepalived -f /usr/local/etc/keepalived.conf If you need to debug keepalived issues, you can run the daemon with the "--dont-fork", "--log-console" and "--log-detail" options: $ keepalived -f /usr/local/etc/keepalived.conf --dont-fork --log-console --log-detail These options will stop keepalived from fork'ing, and will provide additional logging data. Using these options is especially useful when you are testing out new configuration directives, or debugging an issue with an existing configuration file. Locating The Router That is Managing A Virtual IP
To see which director is currently the master for a given virtual interface, you can check the output from the ip utility: VRRP-director1$ ip addr list br0 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:24:8c:4e:07:f6 brd ff:ff:ff:ff:ff:ff inet 192.168.1.6/24 brd 192.168.1.255 scope global br0 inet 192.168.1.100/32 scope global br0:100 inet 192.168.1.101/32 scope global br0:101 inet6 fe80::224:8cff:fe4e:7f6/64 scope link valid_lft forever preferred_lft forever VRRP-director2$ ip addr list br0 5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:24:8c:4e:07:f6 brd ff:ff:ff:ff:ff:ff inet 192.168.1.7/24 brd 192.168.1.255 scope global br0 inet6 fe80::224:8cff:fe4e:7f6/64 scope link valid_lft forever preferred_lft forever In the output above, we can see that the virtual interfaces 192.168.1.100 and 192.168.1.101 are currently active on VRRP-director1. Troubleshooting Keepalived And VRRP
The keepalived daemon will log to syslog by default. Log entries will range from entries that show when the keepalive daemon started, to entries that show state transitions. Here are a few sample entries that show keepalived starting up, and the node transitioning a VRRP instance to the MASTER state: Jul 3 16:29:56 disarm Keepalived: Starting Keepalived v1.1.17 (07/03,2009) Jul 3 16:29:56 disarm Keepalived: Starting VRRP child process, pid=1889 Jul 3 16:29:56 disarm Keepalived_VRRP: Using MII-BMSR NIC polling thread... Jul 3 16:29:56 disarm Keepalived_VRRP: Registering Kernel netlink reflector Jul 3 16:29:56 disarm Keepalived_VRRP: Registering Kernel netlink command channel Jul 3 16:29:56 disarm Keepalived_VRRP: Registering gratutious ARP shared channel Jul 3 16:29:56 disarm Keepalived_VRRP: Opening file '/usr/local/etc/keepalived.conf'. Jul 3 16:29:56 disarm Keepalived_VRRP: Configuration is using : 62990 Bytes Jul 3 16:29:57 disarm Keepalived_VRRP: VRRP_Instance(VRRP_ROUTER1) Transition to MASTER STATE Jul 3 16:29:58 disarm Keepalived_VRRP: VRRP_Instance(VRRP_ROUTER1) Entering MASTER STATE Jul 3 16:29:58 disarm Keepalived_VRRP: Netlink: skipping nl_cmd msg... If you are unable to determine the source of a problem with the system logs, you can use tcpdump to display the VRRP advertisements that are sent on the local network. Advertisements are sent to a reserved VRRP multicast address (224.0.0.18), so the following filter can be used to display all VRRP traffic that is visible on the interface passed to the "-i" option: $ tcpdump -vvv -n -i br0 host 224.0.0.18 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 10:18:23.621512 IP (tos 0x0, ttl 255, id 102, offset 0, flags [none], proto VRRP (112), length 40) \ 192.168.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple, intvl 1s, length 20, addrs: 192.168.1.100 auth "19283746" 10:18:25.621977 IP (tos 0x0, ttl 255, id 103, offset 0, flags [none], proto VRRP (112), length 40) \ 192.168.1.6 > 224.0.0.18: VRRPv2, Advertisement, vrid 100, prio 100, authtype simple, intvl 1s, length 20, addrs: 192.168.1.100 auth "19283746" ......... The output contains several pieces of data that be useful for debugging problems: authtype - the type of authentication in use (authentication configuration directive) vrid - the virtual router id (virtual_router_id configuration directive) prio - the priority of the device (priority configuration directive) intvl - how often to send out advertisements (advert_int configuration directive) auth - the authentication token sent (auth_pass configuration directive) Conclusion
In this article I described how to set up a host to use the keepalived daemon, and provided a sample configuration file that can be used to failover virtual interfaces between servers. Keepalived has a slew of options not covered here, and I will refer you to the keepalived source code and documentation for additional details
在Keepalived集群中，其实并没有严格意义上的主、备节点，虽然可以在Keepalived配置文件中设置“state”选项为“MASTER”状态，但是这并不意味着此节点一直就是Master角色。控制节点角色的是Keepalived配置文件中的“priority”值，但并它并不控制所有节点的角色，另一个能改变节点角色的是在vrrp_script模块中设置的“weight”值，这两个选项对应的都是一个整数值，其中“weight”值可以是个负整数，一个节点在集群中的角色就是通过这两个值的大小决定的。 在一个一主多备的Keepalived集群中，“priority”值最大的将成为集群中的Master节点，而其他都是Backup节点。在Master节点发生故障后，Backup节点之间将进行“民主选举”，通过对节点优先级值“priority”和““weight”的计算，选出新的Master节点接管集群服务。
在vrrp_script模块中，如果不设置“weight”选项值，那么集群优先级的选择将由Keepalived配置文件中的“priority”值决定，而在需要对集群中优先级进行灵活控制时，可以通过在vrrp_script模块中设置“weight”值来实现。下面列举一个实例来具体说明。
假定有A和B两节点组成的Keepalived集群，在A节点keepalived.conf文件中，设置“priority”值为100，而在B节点keepalived.conf文件中，设置“priority”值为80，并且A、B两个节点都使用了“vrrp_script”模块来监控mysql服务，同时都设置“weight”值为10，那么将会发生如下情况。
在两节点都启动Keepalived服务后，正常情况是A节点将成为集群中的Master节点，而B自动成为Backup节点，此时将A节点的mysql服务关闭，通过查看日志发现，并没有出现B节点接管A节点的日志，B节点仍然处于Backup状态，而A节点依旧是Master状态，在这种情况下整个HA集群将失去意义。
下面就分析一下产生这种情况的原因，这也就是Keepalived集群中主、备角色选举策略的问题。下面总结了在Keepalived中使用vrrp_script模块时整个集群角色的选举算法，由于“weight”值可以是正数也可以是负数，因此，要分两种情况进行说明。
1. “weight”值为正数时 在vrrp_script中指定的脚本如果检测成功，那么Master节点的权值将是“weight值与”priority“值之和，如果脚本检测失败，那么Master节点的权值保持为“priority”值，因此切换策略为： Master节点“vrrp_script”脚本检测失败时，如果Master节点“priority”值小于Backup节点“weight值与”priority“值之和，将发生主、备切换。 Master节点“vrrp_script”脚本检测成功时，如果Master节点“weight”值与“priority”值之和大于Backup节点“weight”值与“priority”值之和，主节点依然为主节点，不发生切换。
2. “weight”值为负数时 在“vrrp_script”中指定的脚本如果检测成功，那么Master节点的权值仍为“priority”值，当脚本检测失败时，Master节点的权值将是“priority“值与“weight”值之差，因此切换策略为： Master节点“vrrp_script”脚本检测失败时，如果Master节点“priority”值与“weight”值之差小于Backup节点“priority”值，将发生主、备切换。 Master节点“vrrp_script”脚本检测成功时，如果Master节点“priority”值大于Backup节点“priority”值时，主节点依然为主节点，不发生切换。
在熟悉了Keepalived主、备角色的选举策略后，再来分析一下刚才实例，由于A、B两个节点设置的“weight”值都为10，因此符合选举策略的第一种，在A节点停止Mysql服务后，A节点的脚本检测将失败，此时A节点的权值将保持为A节点上设置的“priority”值，即为100，而B节点的权值将变为“weight”值与“priority”值之和，也就是90（10+80），这样就出现了A节点权值仍然大于B节点权值的情况，因此不会发生主、备切换。
对于“weight”值的设置，有一个简单的标准，即“weight”值的绝对值要大于Master和Backup节点“priority”值之差。对于上面A、B两个节点的例子，只要设置“weight”值大于20即可保证集群正常运行和切换。由此可见，对于“weight值的设置，要非常谨慎，如果设置不好，将导致集群角色选举失败，使集群陷于瘫痪状态。
如果你在读这篇文章，说明你跟大多数开发者一样对GIT感兴趣，如果你还没有机会来试一试GIT，我想现在你就要了解它了。 GIT不仅仅是个版本控制系统，它也是个内容管理系统(CMS),工作管理系统等。如果你是一个具有使用SVN背景的人，你需要做一定的思想转换，来适应GIT提供的一些概念和特征。所以，这篇文章的主要目的就是通过介绍GIT能做什么、它和SVN在深层次上究竟有什么不同来帮助你认识它。 那好，这就开始吧… 1.GIT是分布式的，SVN不是： 这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。如果你能理解这个概念，那么你就已经上手一半了。需要做一点声明，GIT并不是目前第一个或唯一的分布式版本控制系统。还有一些系统，例如Bitkeeper, Mercurial等，也是运行在分布式模式上的。但GIT在这方面做的更好，而且有更多强大的功能特征。 GIT跟SVN一样有自己的集中式版本库或服务器。但，GIT更倾向于被使用于分布式模式，也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库。可以这样说，如果你被困在一个不能连接网络的地方时，就像在飞机上，地下室，电梯里等，你仍然能够提 交文件，查看历史版本记录，创建项目分支，等。对一些人来说，这好像没多大用处，但当你突然遇到没有网络的环境时，这个将解决你的大麻烦。 同样，这种分布式的操作模式对于开源软件社区的开发来说也是个巨大的恩赐，你不必再像以前那样做出补丁包，通过email方式发送出去，你只需要创建一个分支，向项目团队发送一个推请求。这能让你的代码保持最新，而且不会在传输过程中丢失。GitHub.com就是一个这样的优秀案例。 有些谣言传出来说subversion将来的版本也会基于分布式模式。但至少目前还看不出来。 2.GIT把内容按元数据方式存储，而SVN是按文件： 所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。如果你把.git目录的 体积大小跟.svn比较，你会发现它们差距很大。因为,.git目录是处于你的机器上的一个克隆版的版本库，它拥有中心版本库上所有的东西，例如标签，分 支，版本记录等。 3.GIT分支和SVN的分支不同： 分支在SVN中一点不特别，就是版本库中的另外的一个目录。如果你想知道是否合并了一个分支，你需要手工运行像这样的命令svn propget svn:mergeinfo，来确认代码是否被合并。感谢Ben同学指出这个特征。所以，经常会发生有些分支被遗漏的情况。 然而，处理GIT的分支却是相当的简单和有趣。你可以从同一个工作目录下快速的在几个分支间切换。你很容易发现未被合并的分支，你能简单而快捷的合并这些文件。
4.GIT没有一个全局的版本号，而SVN有： 目前为止这是跟SVN相比GIT缺少的最大的一个特征。你也知道，SVN的版本号实际是任何一个相应时间的源代 码快照。我认为它是从CVS进化到SVN的最大的一个突破。因为GIT和SVN从概念上就不同，我不知道GIT里是什么特征与之对应。如果你有任何的线 索，请在评论里奉献出来与大家共享。 更新：有些读者指出，我们可以使用GIT的SHA-1来唯一的标识一个代码快照。这个并不能完全的代替SVN里容易阅读的数字版本号。但，用途应该是相同的。 5.GIT的内容完整性要优于SVN： GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。这里有一个很好的关于GIT内容完整性的讨论 –http://stackoverflow.com/questions/964331/git-file-integrity GIT和SVN之间只有这五处不同吗？当然不是。我想这5个只是“最基本的”和“最吸引人”的，我只想到这5点。如果你发现有比这5点更有趣的，请共享出来，欢迎。
mysql中 myisam 引擎不支持事务的概念，多用于数据仓库这样查询多而事务少的情况，速度较快。
mysql中 innoDB 引擎支持事务的概念，多用于web网站后台等实时的中小型事务处理后台。
而oracle没有引擎的概念，oracle有OLTP和OLAP模式的区分，两者的差别不大，只有参数设置上的不同。
oracle无论哪种模式都是支持事务概念的，oracle是一个不允许读脏的数据库系统。
当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果.
OLTP:
也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。
这样做的最大优点是可以即时地处理输入的数据，及时地回答。也称为实时系统(Real time System)。衡量联机事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间(Response Time)，即用户在终端上送入数据之后，到计算机对这个请求给出答复所需要的时间。OLTP是由数据库引擎负责完成的。
OLTP 数据库旨在使事务应用程序仅写入所需的数据，以便尽快处理单个事务。
OLAP:
简写为OLAP,随着数据库技术的发展和应用，数据库存储的数据量从20世纪80年代的兆（M）字节及千兆（G）字节过渡到现在的兆兆（T）字节和千兆兆（P）字节，同时，用户的查询需求也越来越复杂，涉及的已不仅是查询或操纵一张关系表中的一条或几条记录，而且要对多张表中千万条记录的数据进行数据分析和信息综合，关系数据库系统已不能全部满足这一要求。在国外，不少软件厂商采取了发展其前端产品来弥补关系数据库管理系统支持的不足，力图统一分散的公共应用逻辑，在短时间内响应非数据处理专业人员的复杂查询要求。
联机分析处理（OLAP）系统是数据仓库系统最主要的应用，专门设计用于支持复杂的分析操作，侧重对决策人员和高层管理人员的决策支持，可以根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理，并且以一种直观而易懂的形式将查询结果提供给决策人员，以便他们准确掌握企业（公司）的经营状况，了解对象的需求，制定正确的方案。
第一种：直接启动 安装： tar zxvf redis-2.8.9.tar.gz cd redis-2.8.9 #直接make 编译 make #可使用root用户执行`make install`，将可执行文件拷贝到/usr/local/bin目录下。这样就可以直接敲名字运行程序了。 make install 启动： #加上`&`号使redis以后台程序方式运行 ./redis-server & 检测： #检测后台进程是否存在 ps -ef |grep redis #检测6379端口是否在监听 netstat -lntp | grep 6379 #使用`redis-cli`客户端检测连接是否正常 ./redis-cli 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set key "hello world" OK 127.0.0.1:6379> get key "hello world" 停止： #使用客户端 redis-cli shutdown #因为Redis可以妥善处理SIGTERM信号，所以直接kill -9也是可以的 kill -9 PID 第二种：通过指定配置文件启动 配置文件 可为redis服务启动指定配置文件，配置文件 redis.conf 在Redis根目录下。 #修改daemonize为yes，即默认以后台程序方式运行（还记得前面手动使用&号强制后台运行吗）。 daemonize no #可修改默认监听端口 port 6379 #修改生成默认日志文件位置 logfile "/home/futeng/logs/redis.log" #配置持久化文件存放位置 dir /home/futeng/data/redisData
启动时指定配置文件 redis-server ./redis.conf #如果更改了端口，使用`redis-cli`客户端连接时，也需要指定端口，例如： redis-cli -p 6380
其他启停同 直接启动 方式。配置文件是非常重要的配置工具，随着使用的逐渐深入将显得尤为重要，推荐在一开始就使用配置文件。 第三种： 使用Redis启动脚本设置开机自启动 启动脚本 推荐在生产环境中使用启动脚本方式启动redis服务。启动脚本 redis_init_script 位于位于Redis的 /utils/ 目录下。 #大致浏览下该启动脚本，发现redis习惯性用监听的端口名作为配置文件等命名，我们后面也遵循这个约定。 #redis服务器监听的端口 REDISPORT=6379 #服务端所处位置，在make install后默认存放与`/usr/local/bin/redis-server`，如果未make install则需要修改该路径，下同。 EXEC=/usr/local/bin/redis-server #客户端位置 CLIEXEC=/usr/local/bin/redis-cli #Redis的PID文件位置 PIDFILE=/var/run/redis_${REDISPORT}.pid #配置文件位置，需要修改 CONF="/etc/redis/${REDISPORT}.conf" 配置环境 1. 根据启动脚本要求，将修改好的配置文件以端口为名复制一份到指定目录。需使用root用户。 mkdir /etc/redis cp redis.conf /etc/redis/6379.conf 2. 将启动脚本复制到/etc/init.d目录下，本例将启动脚本命名为redisd（通常都以d结尾表示是后台自启动服务）。 cp redis_init_script /etc/init.d/redisd 3. 设置为开机自启动 此处直接配置开启自启动 chkconfig redisd on 将报错误： service redisd does not support chkconfig 参照 此篇文章 ，在启动脚本开头添加如下两行注释以修改其运行级别： #!/bin/sh # chkconfig: 2345 90 10 # description: Redis is a persistent key-value database # 再设置即可成功。 #设置为开机自启动服务器 chkconfig redisd on #打开服务 service redisd start #关闭服务 service redisd stop http://www.tuicool.com/articles/aQbQ3u
mysql mysqldump 只导出表结构 不导出数据 mysqldump --opt -d 数据库名 -u root -p > xxx.sql 备份数据库
#mysqldump 数据库名 >数据库备份名 #mysqldump -A -u用户名 -p密码 数据库名>数据库备份名 #mysqldump -d -A --add-drop-table -uroot -p >xxx.sql 1.导出结构不导出数据
mysqldump --opt -d 数据库名 -u root -p > xxx.sql 2.导出数据不导出结构 mysqldump -t 数据库名 -uroot -p > xxx.sql 3.导出数据和表结构 mysqldump 数据库名 -uroot -p > xxx.sql 4.导出特定表的结构
mysqldump -uroot -p -B 数据库名 --table 表名 > xxx.sql 导入数据：
由于mysqldump导出的是完整的SQL语句，所以用mysql客户程序很容易就能把数据导入了： #mysql 数据库名 < 文件名 #source /tmp/xxx.sql
Haproxy根目录：F:\SysWork\openSource\haproxy\haproxy1.5.12 配置文件haproxy.cfg如下： global log 127.0.0.1 local0 # maxconn 4096 chroot F:\SysWork\openSource\haproxy\haproxy1.5.12 # uid 99 # gid 99 # daemon nbproc 1 pidfile F:\SysWork\openSource\haproxy\haproxy1.5.12\haproxy.pid debug quiet defaults log 127.0.0.1 local3 mode http option httplog option httpclose option dontlognull option forwardfor option redispatch retries 3 maxconn 8192 balance roundrobin timeout connect 50000 timeout client 50000 timeout server 50000 timeout check 20000 listen httpweb :8100 mode http balance roundrobin option httpclose option forwardfor option httpchk GET /index.html #心跳检测的文件 server httpweb1 localhost:9200 cookie 1 weight 5 check inter 2000 rise 2 fall 3 server httpweb2 localhost:9300 cookie 2 weight 3 check inter 2000 rise 2 fall 3 listen httpservice :8200 mode http balance roundrobin option httpclose option forwardfor option httpchk GET /index.html #心跳检测的文件 server httpservice1 localhost:9200 cookie 3 weight 5 check inter 2000 rise 2 fall 3 server httpservice2 localhost:9300 cookie 4 weight 3 check inter 2000 rise 2 fall 3 listen tcpservice bind 0.0.0.0:8400 mode tcp server tcpservice1 localhost:20880 cookie 5 weight 3 check inter 2000 rise 2 fall 3 listen status 127.0.0.1:8300 stats enable stats uri /status stats auth admin:123456 stats realm (Haproxy\ statistic) 启动命令： F:\SysWork\openSource\haproxy\haproxy1.5.12>haproxy.exe -f haproxy.cfg [WARNING] 240/200829 (11260) : parsing [haproxy.cfg:14] : 'option httplog' not usable with proxy 'tcpservice' (needs 'mo de http'). Falling back to 'option tcplog'. [WARNING] 240/200829 (11260) : config : 'option forwardfor' ignored for proxy 'tcpservice' as it requires HTTP mode. [WARNING] 240/200829 (11260) : config : proxy 'tcpservice' : ignoring cookie for server 'tcpservice1' as HTTP mode is di sabled. Available polling systems : poll : pref=200, test result OK select : pref=150, test result FAILED Total: 2 (1 usable), will use poll. Using poll() as the polling mechanism. [WARNING] 240/200829 (11260) : [haproxy.main()] Cannot raise FD limit to 4019. [WARNING] 240/200829 (11260) : [haproxy.main()] FD limit (256) too low for maxconn=2000/maxsock=4019. Please raise 'ulim it-n' to 4019 or more to avoid any trouble. [WARNING] 240/200830 (11260) : Server httpweb/httpweb1 is DOWN, reason: Layer4 connection problem, info: "Connection ref used", check duration: 1000ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [WARNING] 240/200831 (11260) : Server httpweb/httpweb2 is DOWN, reason: Layer4 connection problem, info: "Connection ref used", check duration: 1000ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] 240/200831 (11260) : proxy 'httpweb' has no server available! [WARNING] 240/200831 (11260) : Server httpservice/httpservice1 is DOWN, reason: Layer4 connection problem, info: "Connec tion refused", check duration: 1000ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [WARNING] 240/200831 (11260) : Server httpservice/httpservice2 is DOWN, reason: Layer4 connection problem, info: "Connec tion refused", check duration: 998ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue. [ALERT] 240/200831 (11260) : proxy 'httpservice' has no server available! 监控页面地址：http://127.0.0.1:8300/status 现在配置文件除了http代理之外，还有tcp代理，http代理就是简单的代理tomcat的请求。把haproxy的请求分发给多个tomcat，而tcp代理我这里是代理的dubbo请求，dubbo启动起来的时候20880端口，但是我们可以通过这里的8400端口提供请求 我们之前都是通过telnet localhost 20880可以看到dubbo控制台，现在可以通过telnet localhost 8400查看dubbo控制台
nginx的根目录是：D:\Sys\server\nginx\nginx-1.9.4\ nginx配置文件目录：D:\Sys\server\nginx\nginx-1.9.4\conf nginx.conf 配置文件如下： #user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; include vhosts/*.conf; }
这个主目录只保留基本配置 include vhosts/*.conf;这句话就是引用虚拟主机目录的配置文件 在该目录下面创建vhosts目录： D:\Sys\server\nginx\nginx-1.9.4\conf\vhosts 虚拟主机(实际里面就是配置upstream和server，然后server里面配置监听端口和serverName，还有location)目录里面的配置文件分别为： www.abin.com.conf www.lee.com.conf www.abin.com.conf的配置为： upstream abin { server localhost:9200 weight=10; } # another virtual host using mix of IP-, name-, and port-based configuration server { listen 8000; server_name www.abin.com abin.com; location / { #反向代理的地址 proxy_pass http://abin; root html; index index.html index.htm; } location /abin { #反向代理的地址 proxy_pass http://abin; root html; index index.html index.htm; } } www.lee.com.conf的配置为： upstream lee { server localhost:9300 weight=10;//这个配置为tomcat的请求地址 } # another virtual host using mix of IP-, name-, and port-based configuration server { listen 8000; server_name www.lee.com lee.com; location / { #反向代理的地址 proxy_pass http://lee; root html; index index.html index.htm; } location /abin { #反向代理的地址 proxy_pass http://lee; root html; index index.html index.htm; } } 测试： http://www.lee.com:8000/ http://www.lee.com:8000/abin
http://lee.com:8000/abin http://www.lee.com:8000/ http://www.lee.com:8000/lee
http://lee.com:8000/lee
我的tomcat服务器的web.xml都配置了<webcome-list>index.html</welcome-list>,
tomcat:9200配置了abin这个java工程，它里面的index.html内容为hello，abin
tomcat:9300配置了abin这个java工程，它里面的index.html内容为hello，lee 那么上面的第二个地址打印hello，abin 那么上面的第四个地址打印hello，lee 本地hosts文件配置为： 127.0.0.1 localhost 127.0.0.1 www.abin.com abin.com 127.0.0.1 www.lee.com lee.com
支付宝这次面试,直接是一波流搞定,没有HR问为毛辞职,职业规划之类的问题,都是直接上干货的,技术. 笔试40分钟,然后带上试卷直接去面试,面试时间长短就不清楚了,我大概面了1个小时左右. 笔试: 1. cookie 和 session 的区别 2. JVM 内存模型 3. SQL注入的原理 4. 悲观锁 和 乐观锁 5. 读程序,输出结果. 关于treemap的 6. linux 基础命令,统计日志中的信息 7. java 分布式集群 8. 一道设计题,具体到数据库的表.大概是淘宝的搜索中,输入手机,会出来很多类型,按品牌按价格区间按手机种类. 还有2道题我记不住了. 面试: 1.介绍你做过的项目,用到的技术,涉及到的模块,然后从项目中问各种技术实现的细节(为了确保你是真的懂了). 2.看你的试卷,喊你讲解做题的思路,以及这样结果的原因.(考的是各位的java基础知识了,这点是绕不过去的,懂了就懂了啊,只有平时多看书) 3.团购6位验证码以及团购成功后,发送到你手机上的条码的实现方式.(第一个问题我说用随机数+时间来验证.第二个问题老实说,我也没答上来,我说用序列,面试官说序列到后期20位以上的时候,用户体验很差的) 4.淘宝上是如何保证库存和订单之间的数据准确性的.(CICS Tuxedo，考点是分布式事务,这个问题我也没答上来,最后他问我有什么问题问他的时候,我就反问的这个问题,面试官人挺好的,给我耐心的讲解了一遍淘宝的实现方式以及 epay的实现方式. 淘宝是通过分布式事物,中间用了一个叫协调者角色的程序,当那边点击购买时,会库存减一,保存一条预扣的状态,但是是个预准备状态,然后做成功后,协调者会在另一个数据库生成订单,然后这个订单也是预状态,等两边都准备好以后,通知协调者,又协调者统一完成这2个数据库的事物,从而达到完成一笔交易的目的,若其中一方失败,则将预扣的数字返回到库存从而实现类似回滚的操作.) 5.索引的原理.能否构建时间索引.时间索引构建后会存在什么问题.(索引原理我是回答的堆表索引的构建原理以及查询原理,但是关于时间索引的问题,我也没回答出个所以然来,看面试官的反馈,好像回答得不够好吧) 6.你们数据库的数据量有多大,(回答:我们是电信方面的系统,表上亿的数据很正常).问:如果保证效率? (我是如此回答的,各位自行结合自身的情况参考.答:后台J OB程序会定期备份,把生产表数据移走,然后备份表也会再备份一次,如此剃度的备份,保证生产库的数据是最小的.然后备份表采用分区和子分区,加上构建战略索引(分析系统的sql,常用 查询字段构建复合索引,以减少每次查询时对表的访问次数)). 7.SQL注入的原理以及如何预防,并举例.(这个相对简单,网上一搜一大片) 8.使用过Memcache么? 用在项目中哪些地方? (答,在门户主机上使用,缓存session,分布式的时候,统一访问这台主机验证用户session是否存在,来维持回话的状态和实现回话同步.又追问:java代码中如何实现访问门户服务器的这个session池子的? 几年前的代码,确实忘记了..于是坦白的说,记不清楚了 ) 这些是主要的问题,当你回答一个大问题时中间还有很多比较碎的追问性质的小问题,总体给我的感觉是,氛围很轻松+愉快的,技术层面上还是需要你真正的理解透彻一些关键技术点,才能做到应付各种追问和给出满意的答案吧.如果只是一知半解想去蒙混过关肯定是不行的,毕竟在支付宝的技术大牛面前,多追问几句,也就把你逼到死角了. 还有一点比较重要的感觉就是,他们比较在意你是否了解当下的一些比较热的技术点,比如淘宝的秒杀,是如何保证高并发下的安全性和性能,新浪微博那种大数据量的发送,怎么就保证正确性和时效性的. 自我感觉面试得很一般,估计希望比较小吧,共享这些希望能给各位小伙伴带来实际上的帮助.
环境 配置Mysql的MasterSlave至少需要两台机器。我这里使用三台虚拟机进行测试。三台机器配置完全一样，MySQL安装的路径也是一样： 第一台：10.1.5.181； Windows 2008 DataCenter + MySQL Community Server 5.6.10.1 第二台：10.1.5.182； Windows 2008 DataCenter + MySQL Community Server 5.6.10.1 第三台：10.1.5.183； Windows 2008 DataCenter + MySQL Community Server 5.6.10.1 第一台10.1.5.181用作master，其他两台用做slave。 配置Master 在10.1.5.181这台服务器上找到MySQL的配置文件my.ini。我的具体路径是在C:\ProgramData\MySQL\MySQL Server 5.6下。 打开配置文件，在最下面添加如下配置： ************************************************************************************ #Master start
#日志输出地址 主要同步使用
log-bin=master-bin.log
#同步数据库
binlog-do-db=test
#主机id 不能和从机id重复
server-id=1
#Master end ************************************************************************************ master的配置比较少，server-id是为这一组master/slave服务器定的唯一id，master/slave服务器中不能重复。在binlog-do-db中填写对象要同步的数据库，如果有多个，用逗号分隔，或再写一行如binlog-do-db=test2。 配置Slave 同样在第二台机器上10.1.5.181找到配置文件my.ini。打开配置文件，在最下面添加如下配置： ***************************************************************************** report-host = 10.1.5.181
report-user = root
report-password = root123
log-bin = slave-bin.log
replicate-do-db = test server-id = 2 ***************************************************************************** 这里需要添加master的IP，连接master的用户名和密码，生产环境中需要新建一个用户专门来处理replication，这里没有新建用户，用root做测试。端口没有配置，就是使用默认的3306，如果端口有变化，则通过report-port=？来配置。log-bin是记录日志的位置。 然后通过命令start slave来启动mysql的复制功能。如果在start slave过程中出现异常： The server is not configured as slave; fix in config file or with CHANGE MASTER TO 可以通过下面语句解决： change master to master_host='10.1.5.181',master_user='root',master_password='root123',master_log_file='master-bin.000001' ,master_log_pos=120; 使用show slave status 命令来查来看运行状态。特别关注两个属性，是否为“Yes”，如果都为“Yes”，则说明运行正常。 Slave_IO_Running：连接到主库，并读取主库的日志到本地，生成本地日志文件 Slave_SQL_Running:读取本地日志文件，并执行日志里的SQL命令。 同样的配置再在第三台机器上配置一下，server-id修改成3。重启slave和master的mysqld服务。然后测试，在三台服务器上都确保有数据库test，然后在master服务器的test数据库上建表和数据，之后再两台slave上面都会看见数据的同步。 Mysql的MasterSlave同步时通过二进制文件进行同步的。在Master端，你可以在C:\ProgramData\MySQL\MySQL Server 5.6\data的master-bin.log日志文件里看见所有同步的sql脚本，master-bin.log是配置master时候输入的。在slave端，你可以在MySQL02-relay-bin类似的文件中找到日志。
http://www.cnblogs.com/haoxinyue/archive/2013/04/02/2995280.html
|