从一个需求出发理解rvalue

需求

一年前在游戏公司做游戏开发,最近突然回想起当时在公司看到的一段代码,其使用方式如下

1
2
3
4
5
Package package;
Object* o = new Object;
package.objects.push_back(o);

package.forEach(setId(1) + setName("adf"));

作用是对包裹中的每一个道具设置id为1, 名字为adf

dubbo基础和开发规范

基本概念

最重要的3个

  • Provider 服务提供着
  • Consumer 服务消费者
  • Registry 注册中心,服务提供者注册服务的地方,服务消费者获取可用服务的地方

两个web应用

  • Admin 服务管理,治理,一个web项目,可对各服务进行管理控制,路由,参数配置,负载均衡等。
  • Monitor 监控,RPC调用次数和调用时间监控

hessian2 vs fst bytecode

class

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
static class Simple implements java.io.Serializable{
private String name;
private int age;


public String getName() {
return name;
}

public void setName(String name) {
this.name = name;
}

public int getAge() {
return age;
}

public void setAge(int age) {
this.age = age;
}

static Simple getSimple() {
Simple simple = new Simple();
simple.setAge(10);
simple.setName("XiaoMing");
return simple;
}
}

git flow使用经验

分支构成

  • master 与线上版本保持绝对一致
  • develop 开发分支,由下文提到的release, feature, hotfix分支合并过后的代码
  • feature 实际功能点开发分支,建议每个功能新建一个feature, 具有关联关系的功能公用一个feature分支
  • release 每一次开发完成之后,从develop创建出来的分支
  • hotfix 修复线上bug分支

cas-循环重定向

设定:

1
2
CAS: cas 服务器
APP: 应用服务器

循环重定向

由于在CAS验证通过,重定向到APP之后,在APP上校验失败导致再次去CAS请求登录,而CAS上为登录成功状态,于是生成新的service-ticket,再次重定向到APP,如此循环

客户端代码问题

因为我们做的单点登录只在CAS上校验账号密码,APP需要根据从CAS中取到的用户id,加载出用户信息和权限信息,若客户端取用户信息代码出错,则会导致循环重定向

数据库配置

若CAS与APP链接的为不同的数据库,两个数据库中用户信息不一致,则客户端找不到用户信息,重定向

网络不通

因为一部分逻辑是通过浏览器重定向,而另一部分是服务器通过http直连通信,若两个服务器之间互相不通,则会导致如下问题

  1. APP->CAS不通,会导致重定向到APP之后,APP校验service-ticket失败,不能从CAS拿到用户id等基本信息,则重定向
  2. CAS->APP不通,单点登出通知失败,不会报错,但是单点登出表现为除当前登出的服务器登出成功之外,其他服务器登出失败(表述的不是很准确,自行理解)

而网络不通一般由以下原因导致

  1. 域名解析失败。若域名为内网自己配置的域名,而服务器的hosts中未加入该域名,则由于dns解析失败导致重定向
  2. 防火墙,当两个服务器部署在不同的机器上时,由于防火墙导致网络不通,导致重定向
  3. docker容器中,访问外部网络不通

。。。 或许还有很多网络不通的原因,根据各种情况自行检查

cas+shiro单点登出的坑

情景

cas server:cas
client server: C1
client server: C2

当用户在C1和C2都登录之后,获取到改用户在两个系统内各自需要的权限之后,在C1做登出操作,按照网上大部分的配置方法(web.xml中增加SingleSignOutFilter和SingleSignOutHttpSessionListener),可以在效果上看起来是登出了,但是并没有完全登出。

即:
C1和C2的JSESSIONID对应在服务器的session被销毁,浏览器两个JSESSIONID失效(看起来登出了)
cas的cookie(TGT)失效
C1服务器上,对应的用户权限清除(C1是完全退出了)
C2服务器上,对应的用户权限没有清除(没完全退出)

,