配置PPPOE拨号

1.配置pppoe拨号接口

ipv6 address auto #配置获得ipv6 地址
ipv6 address dhcp-alloc #配置通过dhcp分配的ip
ipv6 dhcp client pd 11 rapid-commit #配置获得分配ipv6地址的前缀

2.配置dhcpv6 地址池

ipv6 dhcp pool ipv6_pool #定义地址池，将自动进入地址池配置视图
    dns-server 2400:2300::1 # 地址ipv6 dns地址,可以配置多个

dns-server 2400:3200:BABA::1
dns-server 2001:4860:4860::8888
3.配置vlan接口
ipv6 dhcp select server
ipv6 dhcp server apply pool ipv6_pool
ipv6 address 11 ::4:0:0:0:1/64
ipv6 nd autoconfig other-flag
undo ipv6 nd ra halt

注意如果多个接口需要使用同一个地址前缀，需要看运营商分配的前缀的长度类决定。ipv6 地址规定前64位为前缀地址，因此如果运营商设置的是64位，那你就无法配置自己的子网了。
一般运营商给的是50-60位的前缀，因此就利用获得的pd分配自己的子网比如我们在自己vlan下需要设置ipv6地址信息，那就可以采用以下方式，
vlan 1可以配置为pv6 address 11 ::1:0:0:0:1/64
vlan 2可以配置为pv6 address 11 ::2:0:0:0:1/64
vlan 3可以配置为pv6 address 11 ::3:0:0:0:1/64
至于前缀配置配置位数，计算长度的方式为: 64-运营商给的pd长度 剩余的位数就是，后面这个/64是你的网络的主机自动组装位数长度

配置参考
https://www.h3c.com/cn/d_202309/1941005_30005_0.htm

假设树定义如下
tree_table(tree_id varchar(50) primary key,parent_id varchar(50),name varchar(50))

查询如下:
select t2.tree_id from

(select @r as _id,(select  @r:=tree_id from  tree_table where tree_id =_id) 2v2
from(select @r:=#{searchTreeId})vars,tree_tablec
where @r is not null) t1 join tree_tablet2 on t1._id=t2.tree_id )

以上查询结果包含了自身节点

mysql 中 find_in_set不会使用索引，因此如果要使用索引就必须优化处理
假设表结构如下
tree_info (tree_id varchar(50) primary key,parent_id varchar(50),name varchar(50))

select t.tree_id from (

                         select t.tree_id ,if(FIND_IN_SET(t.parent_id,@pids)>0,@pids:=concat(@pids,',',t.tree_id ),-1) as is_child from 
                        (select t.tree_id ,t.parent_id from tree_info t   order by t.parent_id ,t.tree_id )t ,
                        (select @pids:=#{searchTreeId}

可以查询出当前节点的所有子节点

问题出现的情景：
我们在写代码的时候很自然的会用到一些常量，习惯性的我们会定义在某一个类文件类，然后在其他的使用的地方引用这个类中的变量。
然后有一天，由于某些问题导致不得不修改某个已经定义好的常量的的值，这时候我们可能对服务器做增量方式的更新，那我们可能就值更新这常量问题，而其它相关使用这个常量的文件并没有更新，然而。。。。。，奇葩的问题就出现了。

情景案例
class A{
public static final String VERSION="1.0.0";
}
class B{
public static void main(){

 System.out.println(A.VERSION);

}
}
然后某天
我们修改了A
class A{
public static final String VERSION="1.0.1";
}
然鹅我们在服务器上只更新了A文件，并没有更新B文件，这是你会发现打印出来的还是1.0.0，并不是1.0.1

为什么会出现这个奇葩现象呢？

为了跟踪这个问题，我们使用java反编译工具发现，原来B反编译后的代码为：
class B{
public static void main(){

 System.out.println("1.0.0");

}
}
终于根源问题找到了

虽然问题找到了根源，但是为什么会出现这个情况呢？
我们定义常量的目的是为了更好的维护，但是在java编译过程中，由于对代码进行优化出现，自动的将相关常量信息编译自动连接编译到结果里，而不是引用类中的数据。那按这个方式理解，我们修改常某个常量就需要对所有涉及到的文件进行更新，这也就势必要求运维在更新时只能选择全量更新，而不能只更新某一个类文件。

那我的疑问就来了，那是不是我们编译后，这个常量文件是否还有存在的意义呢？

  1. 1
  2. 2
  3. 3