Posts

redis 主从复制 https://lanjingling.github.io/2015/11/17/redis-mast-slaveof/ Redis中,用户可以使用slaveof命令或者slaveof配置项,让一个服务器去复制另一个服务器。进行复制中的主从服务器双方的数据库将保存相同的数据 (一致性) 。 通过命令: 127.0.0.1:6380> slaveof 127.0.0.2 6379 上面的命令表示: 端口为6380的服务器 开始复制 端口为6379的服务器。 通过配置文件: 主服务器不用做任何修改,在从服务器的配置文件中作如下修改: slaveof 192.168.0.100 6379 (映射到主服务器上) 如果master设置了验证密码,还需配置masterauth。楼主的master设置了验证密码为admin,所以配置masterauth admin。配置完之后启动slave的Redis服务,OK,主从配置完成。 在master和slave分别执行info命令,查看结果如下, 主服务器: 9 Replication role:master connected_slaves:1 slave0:ip=127.0.0.2,port=6380,state=online,offset=10394,lag=0 master_repl_offset:10394 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:10393 从服务器: 16 Replication role:slave master_host:127.0.0.2 master_port:6379 master_link_status:up master_last_io_seconds_ago:3 master_sync_in_progress:0 slave_repl_offset:10436 slave_priority:100 slave_read_only:1 connected_slaves:0 master_repl_offset:0 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0 注: 当从服务器执行了slaveof命令后,从服务器中原来的数据将清空,重新加载主服务器中的数据。 Redis2.8版本之前使用了旧版复制功能,2.8之后开始使用新版本的功能。 旧版复制: 旧版复制实现: 复制功能分为同步和命令传播两个步骤: 同步: 将从服务器的数据库状态更新成主服务器当前的数据库状态； 命令传播: 当主服务器的数据库状态被修改,导致主从服务器状态不一致,让主从服务器数据库状态重新回到一致状态； 同步: 当客户端向从服务器发送slaveof命令后,要求从服务器复制主服务器时,从服务器首先要执行同步操作,具体为从服务器向主服务器发送SYNC命令,步骤如下: 从服务器向主服务器发送SYNC命令； 收到SYNC命令的主服务器开始执行bgsave,在后台生成一个rdb文件；并用一个缓冲区记录从现在开始执行的所有写命令； 主服务器bgsave执行完毕后,将rdb文件发送给从服务器；从服务器收到后载入该rdb文件,将从数据库状态更新成主服务器执行bgsave时的状态； 主服务器将记录在缓冲区中的写命令发送给从服务器；从服务器执行这些命令,将其状态更新成主服务器当前的妆台； 命令传播: 在同步操作完毕后,主从服务器达到了一致的状态,但这种状态不是一成不变的。当主服务器执行了写操作后,主服务器会对从服务器执行命令传播操作,将相应的写命令发送给从服务器,从服务器执行该命令,从而达到一致性。 缺陷: 旧版复制过程中,如果主从服器出现断线,当从服务器重新连接上后,这时,由于主从服务器状态不一致,所以从服务器向主服务器发送SYNC命令。这时,主服务器会按照上面的步骤执行bgsave….操作。 ...

tcp MTU MSS MTU: Maxitum Transmission Unit 最大传输单元 检测需要设置的合理的值： 大部分网络设备都是 1500。如果本机的 MTU 比网关的 MTU 大，大的数据包就会被拆开来传送，这样会产生很多数据包碎片，增加丢包率，降低网络速度。把本机的 MTU 设成比网关的 MTU 小或相同，就可以减少丢包 Linux OS 检测网络 MTU: ping -s 1472 -M do 172.21.0.118 含义： 发送大小包大小是 1472（+28）字节，禁止路由器拆分数据包。 【 1472 + 8(ICMP回显示请求和回显应答报文格式长度) + 20(IP首部) = 1500 】 回复结果： 如果正常回复，说明网络允许最大MTU就是1500字节，与系统默认相同，只需将自己的路由的MTU也设置为1500即可。 如果没正常回复，说明数据包大小超过了网络限定的MTU大小。需要减小探测包大小再次尝试。 有些系统或网络 可能会返回建议的 MTU, ping: local error: Message too long, mtu=1364, 在这个值 基础上 -28 就是需要设置的 MTU, ip link set dev ens32 mtu 1336 iproute2 change link MTU 临时修改 MTU 重启后失效 ...

redis 监控 http://ghoulich.xninja.org/2016/12/08/how-to-use-latency-monitor-in-redis/ Redis 2.8.13引入了一个新特性,叫做延迟监控 (Latency Monitoring) ,它可以帮助用户检查和定位可能的延迟问题。延迟监控由下面的几个组件构成: 延迟挂钩: 这个组件会对延迟敏感的各种代码路径进行采样。 时间序列: 这个组件会记录由各种事件造成的延迟飙升。 报告引擎: 这个组件会从时间序列中取出原始数据。 分析引擎: 这个组件会根据测量方法向用户提供易读的报告和提示信息。 本文只会详细描述延迟监控子系统的各项功能。如果想要了解如何检查和定位Redis的延迟问题,请参考《Redis延迟问题的排查方法》。 http://www.jianshu.com/p/68485d5c7fb9 Redis Server监控数据采集 ping,info all, slowlog get/len/reset/cluster info/config get Redis存活监控 redis存活监控 (redis_alive):redis本地监控agent使用ping,如果指定时间返回PONG表示存活,否则redis不能响应请求,可能阻塞或死亡。当返回值不为1时,redis挂了,告警 [root@tzgdevapp10 bin]# ./redis-cli -c -p 7000 ping | grep -c PONG 连接个数 (connected_clients): 客户端连接个数,如果连接数过高,影响redis吞吐量。>5000 时告警 [root@tzgdevapp10 bin]# ./redis-cli -c -p 7000 info | grep -w “connected_clients” | awk -F":" ‘{print $2}’ 连接数使用率(connected_clients_pct): 连接数使用百分比,通过(connected_clients/maxclients)计算；如果达到1,redis开始拒绝新连接创建,告警 拒绝的连接个数(rejected_connections): redis连接个数达到maxclients限制,拒绝新连接的个数。告警 [root@tzgdevapp10 bin]# ./redis-cli -c -p 7000 info | grep -w rejected_connections ...

OPTION SQL_SELECT_LIMIT http://lucifer119.blog.51cto.com/2914308/1344253 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘OPTION SQL_SELECT_LIMIT=DEFAULT’ at line 1 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘OPTION SQL_SELECT_LIMIT=DEFAULT’ at line 1 原因: 项目中我用的jdbc驱动版本 MySQL-connector-java-5.1.15.jar MySQL数据库版本为5.6 jdbc在连接数据库时候会发送测试语句SET OPTION SQL_SELECT_LIMIT=DEFAULT 这在MySQL5.6以下版本是可以的 ,但是5.6不再支持SET… ...

gmail mail filter to:(xxx@xxx.com) after:2015/04/01 before:2016/01/01

nsswitch.conf http://lsscto.blog.51cto.com/779396/904078 /etc/nsswitch.conf文件解释 2008-01-17 15:19:47 标签: nsswitch 文件 conf 休闲 职场 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://songzai.blog.51cto.com/52048/59678 nsswitch.conf是SUN公司开发的一种扩充 (name services switch) DESCRIPTION C 程序库里很多函数都需要配置以便能在本地环境正常工作, 习惯上是使用文件(例如`/etc/passwd’) 来完成这一任务. 但别的名字服务, 如 网络信息服务NIS, 还有域名服务DNS等, 逐渐通用起来, 并且被加入了C 程序库里, 而它们使用的是固定的搜索顺序. 在有NYS 支持的Linux libc5以及GNU C Library 2.x (libc.so.6)里, 依靠一个更清晰完整的方案来解决该问题. 该方案模仿了Sun Microsystems公司在Solaris 2 的C 程序库里的方法, 也沿袭了它们的命名, 称为 “名字服务开关(NSS)”. 所用 “数据库” 及其查找顺序在文 件 /etc/nsswitch.conf 里指明. NSS 中可用数据库如下: aliases: 邮件别名, sendmail(8) 使用该文件. ethers: 以太网号. group: 用户组, getgrent(3) 函数使用该文件. hosts: 主机名和主机号, gethostbyname(3) 以及类似的函数使用了该文件. netgroup: 网络内主机及其用户的列表, 访问规则使用该文件. ...

ld.so.conf http://lsscto.blog.51cto.com/779396/904078 # 列出所有已经安装的共享库 ldconfig -p | less Linux 共享库 Linux 系统上有两类根本不同的 Linux 可执行程序。第一类是静态链接的可执行程序。静态可执行程序包含执行所需的所有函数 — 换句话说,它们是"完整的"。因为这一原因,静态可执行程序不依赖任何外部库就可以运行。 第二类是动态链接的可执行程序。 静态可执行程序与动态可执行程序比较 我们可以用 ldd 命令来确定某一特定可执行程序是否为静态链接的: ldd /sbin/sln not a dynamic executable “not a dynamic executable"是 ldd 说明 sln 是静态链接的一种方式。现在,让我们比较 sln 与其非静态同类 ln 的大小: ls -l /bin/ln /sbin/sln -rwxr-xr-x 1 root root 23000 Jan 14 00:36 /bin/ln -rwxr-xr-x 1 root root 381072 Jan 14 00:31 /sbin/sln 如您所见,sln 的大小超过 ln 十倍。ln 比 sln 小这么多是因为它是动态可执行程序。动态可执行程序是不完整的程序,它依靠外部共享库来提供运行所需的许多函数。 动态链接相关性 要查看 ln 依赖的所有共享库的列表,可以使用 ldd 命令: ...

linux 命令行下使用socks 代理 二、将 Socks5 代理转化为 http 代理 socks5 代理转换成 http 代理需要借助第三方软件完成,这里使用 privoxy,Ubuntu 下使用如下命令安装 privoxy apt-get install privoxy -y 编辑配置文件 先备份原配置文件 mv /etc/privoxy/config /etc/privoxy/config.bak 在新建一个配置文件 vim /etc/privoxy/config privoxy 配置样例如下 转发地址 forward-socks5 / 127.0.0.1:1080 . 监听地址 listen-address localhost:8118 local network do not use proxy forward 192.168../ . forward 10..._/ . forward 127..._/ . 最后启动 privoxy,Ubuntu 16 启动命令如下 启动 systemctl start privoxy 查看状态 systemctl status privoxy 三、创建快捷代理命令 完成上两步配置后,即可将需要代理的软件指向 127.0.0.1:8118 端口即可,但是有些命令行操作并无法设置,只能通过全局代理变量 http_proxy 等设置,此时设置后全局都受影响,为此可以写一个代理脚本,如下 vim /usr/local/bin/proxy 脚本内容如下 !/bin/bash http_proxy=http://127.0.0.1:8118 https_proxy=http://127.0.0.1:8118 $* ...

fat32, fat32 (LBA) http://www.tsingpost.com/articles/201403/480.html fat32和fat32 (LBA) 的区别 LBA(Logical Block Addressing)逻辑块寻址模式 LBA 模式下我们知道硬盘上数据区域由所磁头、柱面 (也磁道) 和扇区所唯确定早期系统直接使用磁头柱面和扇区来对硬盘进行寻址 (称CHS寻址) 需要分别存储每区域三参数 (称3D参数) 使用时再分别读取三参数送磁盘控制器去执行由于系统用8b来存储磁头地址用10b来存储柱面地址用6b来存储扇区地址而扇区共有512B样使用CHS寻址块硬盘大容量256 * 1024 * 63 * 512B = 8064 MB(1MB = 1048576B) (若按1MB=1000000B来算8.4GB) 随着硬盘技术进步硬盘容量越来越大CHS模式无法管理超过8064 MB硬盘因此工程师们发明了更加简便LBA寻址方式LBA地址地址再表示实际硬盘实际物理地址 (柱面、磁头和扇区) LBA编址方式 CHS种三维寻址方式转变维线性寻址把硬盘所有物理扇区C/H/S编号通过定规则转变线性编号系统效率得大大提高避免了烦琐磁头/柱面/扇区寻址方式访问硬盘时由硬盘控制器再种逻辑地址转换实际硬盘物理地址 VFAT 作为FAT文件系统的一种扩展，VFAT在Windows 95中首次引入。VFAT在保持针对FAT向后兼容能力的同时，大大放宽了各项规范。举例来说，VFAT文件名中最多可以包含255个字符，并且允许使用空格或多个句点。尽管VFAT能够保持文件名的大小写状态，然而它同样无法对其加以区分。 当您通过VFAT创建一个长文件名 (长度超过8.3）时，文件系统实际上同时创建了两个文件名。其中一个为实际输入的长文件名，这个文件名对于Windows 95、Windows 98和Windows NT (4.0及更高版本）是可见的。另一个文件名为DOS下所使用的别名，该文件名为长文件名的缩写。这个DOS别名由长文件名中的前六个字符 (不包含空格）、代字符 (~）以及数字后缀所组成。 VFAT文件系统存储长文件名的方式产生了一个有趣的副作用。当您在VFAT文件系统中创建一个长文件名时，VFAT将为DOS别名分配一个目录项，为长文件名中的每13个字符分配一个目录项。从理论上讲，一个长文件名最多可以占用21个目录项。一般情况下，根目录中最多可以包含512个文件，然而，如果在根目录中使用最大长度的文件名，那么，上述限制条件将缩小的最多包含24个文件。由此可见，应当尽可能避免在根目录中使用长文件名。除根目录外，其它目录均不受这一制约因素的限制。 我们之所以在这里对VFAT进行讨论，主要是因为这种文件系统的应用范围比FAT更加广泛。除以上所提到的不同之处外，这两种文件系统在其它方面遵守相同的规范。当您在Windows NT中使用FAT对某一分区进行格式化时，该分区实际将被格式化为VFAT。在Windows NT 4.0系统环境下，您唯一可能接触真正FAT分区的方式便是使用由其它操作系统 (如MS-DOS）完成格式化的分区。 https://blog.csdn.net/tesport/article/details/5581699

java maven 可执行 jar/ executable jar, maven-assembly-plugin 在pom中加入 maven-assembly-plugin <project> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>3.3.0</version> <configuration> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> <archive> <manifest> <mainClass>com.wiloon.java.lock.TestFutex</mainClass> </manifest> </archive> </configuration> <executions> <execution> <phase>package</phase> <goals> <goal>single</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project> mvn clean package assembly:single # 如果没执行过 mvn package 会报错： Cannot include project artifact: com.wiloon.java:pingd-java:jar:1.0-SNAPSHOT; it doesn't have an associated file or directory. java -jar target/pingd-java-1.0-SNAPSHOT-jar-with-dependencies.jar

zookeeper leader latch, leader election https://curator.apache.org/zk-compatibility.html curator-framework 4.x 同时支持 zookeeper 3.4.x, 3.5.x curator4 默认依赖zookeeper 3.5 使用zookeeper3.4时,需要把zookeeper排除掉,再依赖zookeeper3.4 <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>${curator-version}</version> <exclusions> <exclusion> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> </exclusion> </exclusions> </dependency> leader latch/leader election 在分布式计算中, leader election 是很重要的一个功能, 这个选举过程是这样子的: 指派一个进程作为组织者, 将任务分发给各节点。 在任务开始前, 哪个节点都不知道谁是 leader 或者 coordinator. 当选举算法开始执行后, 每个节点最终会得到一个唯一的节点作为任务 leader. 除此之外, 选举还经常会发生在 leader 意外宕机的情况下, 新的 leader 要被选举出来。 Curator 有两种选举recipe, 你可以根据你的需求选择合适的。 public LeaderLatch(CuratorFramework client, String latchPath) public LeaderLatch(CuratorFramework client, String latchPath, String id) 必须启动LeaderLatch: leaderLatch.start(); 一旦启动, LeaderLatch会和其它使用相同latch path的其它LeaderLatch交涉,然后随机的选择其中一个作为leader。 你可以随时查看一个给定的实例是否是leader: ...

redis 集群/cluster redis 工作在集群模式的时候除了常规的 tcp 端口 6379, 还需要一个额外的 TCP 端口跟集群内的其它节点通信, 端口号是在 tcp 端口基础上加一个固定的偏移量 10000, 6379 + 10000 = 16379 https://rajivsharma-2205.medium.com/enable-tcp-keepalive-on-redis-cluster-bus-153128e412fa redis5.0.x 上 redis-trib.rb 工具不再可用，redis-trib.rb 相关的全部功能，已迁移到 redis-cli –cluster 命令上了。 # 创建集群主节点 redis-cli --cluster create 192.168.163.132:6379 192.168.163.132:6380 192.168.163.132:6381 # 创建集群主从节点 /redis-cli --cluster create 192.168.163.132:6379 192.168.163.132:6380 192.168.163.132:6381 192.168.163.132:6382 192.168.163.132:6383 192.168.163.132:6384 --cluster-replicas 1 # 集群信息查看 redis-cli --cluster info 192.168.163.132:6384 # 检查集群状态 redis-cli --cluster check 192.168.163.132:6379 # 检查集群, 检查是否有槽同时被分配给了多个节点 redis-cli --cluster check 192.168.163.132:6384 --cluster-search-multiple-owners # 修复集群 redis-cli --cluster fix 192.168.163.132:6384 --cluster-search-multiple-owners # 添加集群主节点 redis-cli --cluster add-node 192.168.163.132:6382 192.168.163.132:6379 # 说明: 为一个指定集群添加节点，需要先连到该集群的任意一个节点IP (192.168.163.132:6379) ，再把新节点加入。这两个参数的顺序有要求: 新加入的节点放前面 # 添加集群从节点 redis-cli --cluster add-node 192.168.163.132:6382 192.168.163.132:6379 --cluster-slave --cluster-master-id 117457eab5071954faab5e81c3170600d5192270 说明: 把6382节点加入到6379节点的集群中，并且当做node_id为 117457eab5071954faab5e81c3170600d5192270 的从节点。如果不指定 --cluster-master-id 会随机分配到任意一个主节点。 # 删除节点 redis-cli --cluster del-node 192.168.163.132:6384 f6a6957421b00009106cb36be3c7ba41f3b603ff # 说明: 指定 IP, 端口和 node_id 来删除一个节点，从节点可以直接删除，主节点不能直接删除，删除之后，该节点会被shutdown。 # 修复集群 redis-cli --cluster fix 192.168.163.132:6379 cluster # 当前连接节点所属集群的配置信息 ./redis-cli -p 7000 cluster nodes # 人工故障切换, 该命令只能在群集slave节点执行 redis-cli -p 7000 CLUSTER FAILOVER # http://www.redis.cn/commands/cluster-failover.html redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 --cluster-slave redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 --cluster-slave --cluster-master-id 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e ./redis-cli -p 7006> cluster replicate 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e redis-cli --cluster del-node 127.0.0.1:7000 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e ./redis-cli --cluster check 127.0.0.1:7000 # 查看集群状态 cluster info 返回值 cluster_state：状态是ok节点是否能够接收查询。fail状态表示有哈希槽没有被绑定到任意一个节点或者节点可以提供服务但是带有fail标记，或者该节点无法连续到多数master节点 cluster_slots_assigned：与某个节点关联的槽数（不是未绑定的）。这个数字应该是16384，节点才能正常工作，这意味着每个散列槽应该映射到一个节点。 cluster_slots_ok：哈希槽状态不是Fail和PFail的数量 cluster_slots_pfail：哈希槽状态是PFAIL的数量。请注意，只要PFAIL状态不由FAIL故障检测算法提升，这些散列槽仍可正常工作。PFAIL仅意味着我们目前无法与节点通话，但可能只是一个暂时的错误。 cluster_slots_fail：哈希槽状态是FAIL的数量。如果此数字不为零，则该节点无法提供查询，除非在配置中cluster-require-full-coverage设置为no。 cluster_known_nodes：群集中已知节点的总数，包括处于握手（HANDSHAKE）状态还没有称为集群正式成员的节点 cluster_size：至少包含一个哈希槽而且能够提供服务的master节点数量 cluster_current_epoch：集群本地Current Epoch变量的值，这个值在节点故障转移期间创建的独特的自增版本号 cluster_my_epoch：我们正在与之交谈的Config Epoch节点。这是分配给此节点的当前配置版本。 cluster_stats_messages_sent：通过node-to-node二进制总线发送的消息数量 cluster_stats_messages_received：通过node-to-node二进制总线接收的消息数量 redis cluster哈希槽数量 16348=16k, 用 bitmap 来压缩心跳包的话, 就相当于使用 2_8_10=2KB 大小的心跳包。而如果用 crc16 算法( redis使用这个而不是用哈希一致性算法)来确定哈希槽的分配。他的最大值是是2的16次方。用上面的算法换算需要8KB的心跳包来传输, 作者自己认为这样不划算。而一个redis节点一般不会有超过 1000 个master(这个是作者自己说的), 用16k 来划分是比较合适的 ...

MarketInfo 对于当前不同的货币对最小价格的改变也将不同。这个值通常等于 0.01,对于货币对 EURUSD 为 0.0001。在当前开价中这个最小价格改变被称为 点,可以使用函数获取: MarketInfo(Symbol(), MODE_POINT); http://hance66.blog.163.com/blog/static/34583613201051911265533/

ES Modules, or ECMAScript Modules foo.js class ArticleNode { constructor(node, paragraph) { this.node = node this.paragraph = paragraph } } export function createOneArticleNode(){ let articleNode0 = new ArticleNode('foo', 'bar') console.log('a n: ', articleNode0) } bar.js // jest test import { createOneArticleNode } from '../content_module.js' test('test es module 0', () => { console.log('print foo') createOneArticleNode() console.log('print bar') }); npm run test

秒的换算, ms(毫秒), μs(微秒), ns(纳秒), ps(皮秒) http://blog.chinaunix.net/uid-28458801-id-4144886.html 皮秒 皮秒,符号ps (英语: picosecond ) 1皮秒等于一万亿分之一秒 (10-12秒) 1,000 皮秒 = 1纳秒 1,000,000 皮秒 = 1微秒 1,000,000,000 皮秒 = 1毫秒 1,000,000,000,000 皮秒 = 1秒 纳秒 纳秒,符号ns (英语: nanosecond ) 1纳秒等于十亿分之一秒 (10-9秒) 1 纳秒 = 1000皮秒 1,000 纳秒 = 1微秒 1,000,000 纳秒 = 1毫秒 1,000,000,000 纳秒 = 1秒 微秒 微秒,符号μs (英语: microsecond ) 1微秒等于一百万分之一秒 (10-6秒) 0.000 001 微秒 = 1皮秒 0.001 微秒 = 1纳秒 1,000 微秒 = 1毫秒 1,000,000 微秒 = 1秒 毫秒 毫秒是一种较为微小的时间单位，是一秒的千分之一。 ...

Kubernetes Kubernetes是Google开源的容器集群管理系统,其提供应用部署、维护、 扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用,其主要功能如下: 使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。 以集群的方式运行、管理跨机器的容器。 解决Docker跨机器容器之间的通讯问题。 Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态。 当前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台,除此之外,也可以直接运行在物理机上。

ima symbol 用来计算MA指标的货币代码,NULL表示用当前货币 timeframe 时间周期, 可以为PERIOD_M1表示M1, PERIOD_M5表示M5 等等…, 0表示当前图表的时间周期. ma_shift 表示MA指标相对于图标数据的偏移 shift 数据相对当前的最后一条的偏移. period 均线参数

技术分析 一、道琼斯理论 这一技术分析中最古老的理论认为,价格能够全面反映所有现存信息,可供参与者 (交易商、分析家、组合资产管理者、市场策略家及投资者) 掌握的知识已在标价行为中被折算。由不可预知事件引起的货币波动,比如神的旨意,都将被包含在整体趋势中。技术分析旨在研究价格行为,从而做出关于未来走向的结论。 主要围绕股票市场平均线发展而来的道琼斯理论认为,价格可演释为包括三种幅度类型的波状——主导、辅助和次要。相关时间周期从小于3周至大于1年不等。此理论还可说明反驰模式。反驰模式是趋势减缓移动速度所经历的正常阶段,这样的反驰模式等级是33%、50%和66%。 二、斐波纳契反驰现象 这是一种广为使用,基于自然和人为现象所产生的数字比率的反驰现象组。此现象被用于判断价格与其潜在趋势间的反弹或回溯幅度大小。最重要的反驰现象等级是38.2%、50%和61.8%。 三、埃利奥特氏波 埃利奥特派学者以固定波状模式将价格走向分类。这些模式能够表示未来的指标与逆转。与趋势同向移动的波被称为推动波,而与趋势反向移动的波被称为修正波。埃利奥特氏波理论分别将推动波和修正波分为5种和3种主要走向。这8种走向组成一个完整的波周期。时间跨度可从15分钟至数十年不等。 埃利奥特氏波理论具有挑战性的部分在于,1个波周期可用8个子波周期组成,而这些波又可被进一步分成推动和修正波。因此,埃利奥特氏波的关键是能够识别特定波所处的环境。埃利奥特派也使用斐波纳契反驰现象来预测未来波周期的峰顶与谷底。http://www.icbc.com.cn/ICBCCollege/client/page/KnowledgeDetail.aspx?ItemID=634154033509794397

基本面分析 投资者每天都在接触基本面方面的信息和各种研究报告,每天也会有不少专家给投资者分析市场的供求关系以及宏观经济环境,但交易结果并未因此而有大的改观,为什么呢？因为不知道应该如何利用基本面的分析。其实,就普通投资者而言,基本面分析有哪些特征和作用都不甚明了,大多数人要么盲从、要么拒绝基本面的分析,这样做的话,基本面对于他们来讲自然就几乎毫无意义了。 我们该如何定位基本面在交易中的作用呢？ 基本面的分析一般都含有大量的数据和图表,好的报告中数据不仅全面且相当准确,大部分都是研究人员自己搜集整理的,有的甚至是自己去企业考察而来的。研究人员通过大量的数据和图表的分析,会得出一个结论: 市场未来上涨和下跌的可能性有多大。这样的报告肯定是具有价值的,也会得到行业专家或学者的认可,自然也会得到大部分投资者的认可。 其实,我们认可的不仅仅是这份报告,更多的是认可这种分析研究的方法与精神,很多投资者会用这种分析思考的方法来进行交易,但很快就会发现这样做在交易中似乎困难重重,市场的走势经常与他得到的基本面分析背道而驰,也与很多专家的分析背道而驰。这令人十分困惑。为什么呢？因为他不清楚,研究报告可以得到专家学者的认可,但能否得到市场的认可则难以确定,而市场才是唯一的权威和裁判。 很多人通过基本面的分析来预测市场的未来,认为通过研究基本面的情况可以得出市场未来的方向,误以为基本面分析的作用就是预测市场的未来,误以为掌握了大量的基本面资料就可以掌握未来。这是一个根本性的错误,并不是说基本面的分析没有作用,而是说基本面分析的功能不是预测市场,它的作用更多的是告诉我们市场价格波动的原因,使我们更清楚地认识和了解市场,不至于因为对基本面情况的一无所知而对市场价格的涨跌感到迷茫和恐惧。 基本面分析不具有预测市场未来方向的功能,这个功能是人们获利的欲望强加给它的。基本面分析只是客观地告诉投资者市场上发生了什么以及市场价格是如何反应的,在某些情况下,我们甚至根本无法从基本面上找到价格涨跌的原因。 一、基本面包括很多内容,除了商品的供求关系之外,还有本国及全球的经济情况、政策等因素,还包括天气、自然灾害等内容。可以说,不仅没有人甚至没有机构能全面了解基本面的情况,只是谁了解得多谁了解得少而已。市场上永远存在对价格有影响而你又不知道的基本面情况,你所掌握的基本面资料永远不会是全面的。而不全面的、不及时的资料对交易来说就是错误的资料,因为你所掌握的资料不一定能给你带来利润,但你所不了解的情况常常会给你带来伤害。市场经常会出现你无法理解的行情,这意味着市场已经出现了你不知道的新变化,市场上时刻都会出现你不知道的情况。 二、基本面未来的变化和市场价格一样无法预测,未来的市场价格是由未来的基本面情况决定,而不是由目前的基本面情况所决定,我们无法用目前所掌握的静态的基本面情况来分析和预测未来动态变化的市场。人们经常讲: 基本面利多,为什么股价却下跌？股价已经跌破成本价了,怎么还在跌？基本面一片利好,可股价为什么不涨？这是犯了用静态的基本面来对应动态的市场价格的错误。 三、其实,并不是基本面的变化赶不上价格的变化,而是投资者了解基本面变化的速度永远赶不上市场价格变化的速度。市场趋势的改变肯定是因为市场本身的供求关系或整个经济周期发生了根本性的变化所导致,资金的运作不可能改变市场趋势。然而,在任何一次市场发生趋势性转变的时候,我们所能知道的基本面都还处于原来的趋势方向,市场已经改变运行方向了,但投资者还是把它看成是调整,因为基本面还没有改变,一般要等股价回落1/3甚至1/2时,人们才开始担忧基本面是否发生变化了？市场是否转势了？具体来讲,企业感到很不舒服了,而投资者的高位头寸已深度套牢了,这时各种基本面发生根本性改变的报道才会出现。 以上都是基本面分析的不足之处,或者说投资者对基本面的使用不当所造成的不利之处。其实,基本面分析有它自己的优势所在-基本面的情况不会轻易发生根本性的改变,市场一旦形成某种趋势,这个趋势就不会轻易结束,将运行相当长的时间,基本面具有相对的稳定性,它不会跟市场价格一样天天在变化。任何涨势的形成必然是由原来的熊势所导致,长期熊势导致供给减少、产能萎缩和对这个行业资金投入的减少,这个过程是慢慢形成的。这种状态一直会延续到某一个时期市场突然感到商品开始供不应求了,这时价格第一个开始反映,那就是上涨,而价格的上涨会带来利润的增加,企业又开始增加投入,从开始投入到产品上市绝不是几天时间就能做到的。所以,只要基本面发生根本的改变导致新的趋势开始,我们就可认为趋势还将延续,此时若再配合一些简单的技术工具,就能很好地利用基本面的研究成果来获得交易利润,这才是基本面分析最有价值之所在。 其实,基本面分析主要的作用是使投资者更清楚地认识和了解市场目前的状况,更好地跟上市场运行的步伐,制定适应市场的交易策略,并根据新的情况来调整自己的交易计划,而不是预测市场的未来。在交易中,必须以价格为依据、以市场为中心来进行交易,而不能以基本面数据为依据、以自己的判断为中心来进行交易,因为我们所掌握的基本面数据肯定不是全面和及时的,所以必须通过市场价格来检验我们的分析是否正确。 基本面和技术面分析的作用其实都是为了使投资者更好地了解市场,使投资者更好地跟上市场前进的步伐,并因此制定出适应目前市场情况的交易策略,而不是预测市场的未来。 所以,从本质上看,基本面分析与技术分析是完全一样的,它们都不具有预测市场的功能,其本质都是使投资者通过了解市场来更有效地跟踪市场。 (摘自和讯网) http://www.icbc.com.cn/ICBCCollege/client/page/KnowledgeDetail.aspx?ItemID=634154033280626345

自由外汇 自由外汇又称"自由兑换外汇"、“现汇”,是指不需要外汇管理当局批准可以自由兑换成其他国家货币,或者是可以向第三者办理支付的外国货币及支付手段。世界上有50多种货币是可自由兑换货币,其中主要有美元、英镑、德国马克、日元、港币、瑞士法郎、新加坡元、加拿大元、澳大利亚元、丹麦克朗、挪威克朗、瑞典克朗、新西兰元等货币,以及用这些货币表示的汇票、支票、股票、债券等支付凭证和信用凭证,均为自由外汇。 自由外汇在国际金融市场上可以自由买卖,在国际结算中广泛使用,在国际上得到偿付并可以自由兑换其他国家货币。发行这些货币的国家对外汇管制和掌握较松,有的甚至基本上取消了外汇管制,但有些国家则实行严格的外汇管制,本国货币不能自由兑换成国际通用的外币,并规定本国货币不能携出入国境。http://www.icbc.com.cn/ICBCCollege/client/page/KnowledgeDetail.aspx?ItemID=634154032334721923