今天完成的事情：

   @RequestMapping(value = "register", method = RequestMethod.GET)
    public String register() {
        return "register";
    }

    /**
     * （腾讯云）短信验证
     *
     * @param phone
     * @param request
     */
    @ResponseBody
    @RequestMapping("tencentsms")
    public Map<String, Object> tencentSMS(String phone, HttpServletRequest request) {
        JSONObject json = new JSONObject();
        /*验证手机号是否为空*/
        if (phone == null || phone.equals("")) {
            json.put("status", -1);
            json.put("message", "手机号为空");
            return json;
        }
        /*验证手机号是否合法*/
        if (!phone.matches("^[1][3578]\\d{9}$")) {
            json.put("status", -1);
            json.put("message", "手机号非法格式！");
            return json;
        }
        /*生成手机验证码，并限定有效时间。*/
        String code = VerificationUtil.getVerificationCode();
        HttpSession session = request.getSession();
        session.setAttribute("code", code);
        session.setMaxInactiveInterval(180);
        int appid = 1400081087; // 短信应用SDK AppID
        String appkey = "1c3794ed0ce290f07922b3208e364d30";// 短信应用SDK AppKey
        try {
            SmsSingleSender ssender = new SmsSingleSender(appid, appkey);
            SmsSingleSenderResult result = ssender.send(0, "86", phone,
                    "您的验证码是" + code + "，请在三分钟内完成验证。", "", "");
            LOGGER.info(result + "");
            json.put("status", 1);
            json.put("message", "手机验证码发送成功，请查收！");
            return json;
        } catch (HTTPException e) { //这种异常，后端返回给前端异常码，前端给用户提示短信发送失败
// HTTP响应码错误
            e.printStackTrace();
            json.put("status", -1);
            return json;
        } catch (JSONException e) {
// json解析错误
            e.printStackTrace();
            json.put("status", -1);
            return json;
        } catch (IOException e) {
// 网络IO错误
            e.printStackTrace();
            json.put("status", -1);
            return json;
        }
    }

       今天早上弄了一上午加中午的时间找各种 短信验证还有邮箱验证,但是应该是网上下的接口有问题,到底电脑中毒了......清了半天毒,回头看代码的短语验证还有问题.....

       估计有有人吧病毒放到jar包里面了.....下午找了一下接口,没有头绪后,看了一下nginx的负载均衡,因为我的远程服务器启动太多东西在跑压力测试的时候会卡死

关于服务器负载均衡（SLB）

这里写几个名词，Client：客户端，请求源地址（A）  RS：负载均衡时真正的后端服务器（B）  VIP：负载均衡服务器地址 （C)

一、SLB作用

       在多个服务器部署项目的情况下，从Client传来大量请求报文，VIP通过优化算法选取合适的RS处理报文，避免出现有些RS处理过多请求宕机但是有些RS的性能没有用上的情况。

二、SLB的三种传输方式

       七层SLB与四层SLB：

       四层SLB：配置VIP的服务类型为TCP/UDP，VIP的报文解析只有4层，在与Client建立3次TCP握手连接之后就会和RS建立连接。

       七层SLB：配置VIP的服务类型为http/ftp/https，VIP的报文将解析到第7层，在于Client建立7次连接后，只有收到对应7层报文才会和RS建立链接。   

        以下是三种链接方法，无论是哪种连接方法报文都要经过VIP。

1.反向代理（

   我们现在任务里通过nginx配置的基本都是反向代理模式，过程如下：

  （1）Client与VIP通过3次TCP握手建立链接，此时源地址为A，请求地址为C

  （2）VIP接受到Client请求后通过算法计算出最优RS，然后与最优RS通过3次TCP握手建立链接，并将（1）中的报文源地址修改为C，目标地址修改为B，发送给RS

  （3）RS接受到（2）中修改过的报文，处理请求，返回报文源地址B、目标地址C

  （4）VIP接受到(3)中的报文，修改目标地址为A、源地址为C，返还给Client

此时一次请求结束，客户端的请求地址和接受到的源地址均为C。

2.透传模式

   （1）Client于VIP通过3次TCP握手建立链接，此时源地址为A，请求地址为C

    （2）VIP接受到Client请求后通过算法计算出最优RS，然后与最优RS通过3次TCP握手建立链接，将（1）中的目标地址改为B（源地址A不改变，即RS在这个过程中感受不到VIP的存在，受到的报文请求源地址就是Client的地址A

     （3）RS处理（2）中的请求，返回报文，源地址B，目标地址A，但是此时需要配置VIP地址，如果不配置VIP地址那么此次返回会失败

     （4）VIP接受到（3）中的请求，将源地址改为C，目标地址A，返给Client

3.三角模式

  三角模式中RS中存放地址B，所以可以直接传到RS中

     （1）Client与VIP通过3次TCP握手建立链接，发送报文，原地址为A，请求地址为C

       （2）VIP收到此请求，和最优RS通过3次TCP握手建立链接，将报文转发给RS，原地址为A，请求地址为C

       （3）RS处理请求，返回报文源地址B，目标地址A

     在三角模式中由于回复报文的负载均衡设备不做任何处理，所以非常适合RS到Clientt方向流量较大的数据，采用三角模式时必须注意RS有路由可以达到Client，且RS接口上必须有VIP的地址。

顺便

明天计划的事情：

       任务7的思路比较乱 需要帆哥进行一下任务讲解
遇到的问题：

        思路不清晰...
收获：

         网上不能随便下东西