点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！listener是建立实例和客户端进程之间联系的桥梁，listener与实例之间的联系，就是通过注册的过程来实现的。注册的过程就是实例告诉监听器，它的数据库数据库实例名称instance_name和服务名service_names。监听器注册上这样的信息，对客户端请求根据监听注册信息，找到正确的服务实例名称。目前Oracle版本中，提供动态注册和静态注册两种方式。而客户端与实例的连接是直接与实例IP进行通讯的，也就是说只是在初期的连接阶段借用了scan_ip提供的负载平衡功能，后续的客户端和服务端的交互是不经过scan_ip的。这样是解释是合理的，否则failover时，客户端已和服务端建立的连接无法维持，需要重新握手认证。Failover是RAC容错的一个重要方面功能，其功能是在数据库实例崩溃的时候，可以自动将请求转移到其他可用实例上的一种功能。可以提供很大程度上的可用性（Availability）功能。这个过程中，发现实例已经崩溃，并且将请求转移到其他实例上，就属于是listener的功能。
已启动的oracle rac环境的其中一个节点，1521端口已在public ip和private ip上监听。该环境的scan_listener的监听端口为1522，下面会提及。
可以看到scan_listener在节点1上运行，名称为LISTENER_SCAN1,可以看到默认的情况下，这两个称谓不一样，也就是说srvctl status scan_listener 和listener status LISTENER_SCAN1的命令的后面并不一样。使用oracle的sql developer来连接scan_ip, ip是192.xxx.xxx.140，端口1522。查看windows主机的IP为192.xxx.xxx.1。查看1521端口的连接，可以看到来自192.xxx.xxx.1:61680和192.xxx.xxx.132:1521建立了连接，这里并不是192.xxx.xxx.140，因此确认了上面的论述。
查看该主机的网卡信息，发现192.xxx.xxx.140IP相关网卡在线。
普通的监听器也在线，listener在130、132两个IP上。scan_listener也在线，在140上，端口为1522。继续看关于1522端口的网络连接信息，并依次在新开了2个窗口，可以看到来自192.xxx.xxx.1与192.xxx.xxx.140的网络转入到了TIME_WAIT，并最终消亡，可见，scan_ip在此过程中是起到桥梁作用的，像中介一样。
REMOTE_LISTENER参数主要用于RAC环境中监听器的远程注册，监听器的远程注册主要用于实现负载均衡。oracle是把实例和监听器解耦的，所以一个监听器可以为多个oracle实例服务。在rac环境中，有普通的listener和scan_listener，而scan_listener真正的发挥作用，还需要remote_listener参数，如果不设置该参数，则从实例角度看，是不知道外面存在监听器的，就没向scan_listener注册。oracle可以向默认的本机1521端口注册信息。在没向scan_listener注册的情况下，为什么也能通过scan_listener连接到服务端呢，因为scan_ip会在群集中的其中一台服务器上运行，所以该情况下是可以连接的，但是这样是没有负载能力的，在生产环境中笔者就遇过这样的情况，发现集群中的会话不平衡，根本原因是没有设置remote_listener参数，这个问题在scan_listener能工作的情况且客户端也存在大量直连实例IP的情况下比较隐晦。关于漂移：
Oracle会根据当前RAC集群环境中所有实例的负载情况，避开负载较高的实例，将请求转移到负载较低的实例进行处理。在早期RAC版本中，负载轻重的衡量是根据监听器当前维护连接数目来确定的，而不是实时查看多实例的负载.
