CAS

本公众号之前发过几篇多组态（multi-configurational）方法的介绍： 用Gaussian做CASSCF计算 用Gaussian寻找圆锥交叉点 广义价键波函数（GVB）简介 广义价键计算及初始轨道的构造 GVB和CASSCF在精度上通常仅是定性正确，定量上差强人意，若需要高精度的结果或与实验值对比，需要进一步做多参考态（multi-reference）方法的计算。GVB、CASCI、CASSCF和DMRG这些（本质上）是多组态波函数，它们是多参考态方法的参考态（reference）。最最常见的多参考态方法有CASPT2、NEVPT2和MRCISD三种，基于CAS或DMRG参考态的都有很多文章发表，相应可以称为CASSCF-NEVPT2、DMRG-NEVPT2等。D. G. Truhlar和L. Gagliardi等人还提出过基于CAS的MC-PDFT方法，后来也推广到了DMRG-PDFT，由于动态相关是用DFT考虑的，比前述几种多参考态方法计算上经济一些。 多组态或多参考态方法计算步骤复杂，要求用户有 丰富的计算经验 和 较强的化学直觉 ，很多计算（注意仅是写输入文件就）需要有电子结构方法的基础知识。近年来有不少半自动或全自动做多参考态计算的文章发表，意图使这些计算像HF/DFT计算一样简便，但是基本是在文献上或某些课题组里，可获取的程序极少。

市面上绝大多数的系统都具有充值（支付）功能。具有自有账户体系的系软件统往往还具有提现（代付）功能。支付/代付对接大休上可以分为四个阶段 第一阶段：支付代码嵌入到业务代码 优点：简单，无分布式事务问题 缺点：伸缩性差，可扩展性差，项目管理角度来看不好明确分工 第二阶段：服务化，单独的支付服务 优点：伸缩性，扩展性强，与具体的业务系统解耦，人员分工更合理 缺点：分布式事务问题 第三阶段：系统化，公司内部单独的支付系统 实现支付路由等更多的技术与非技术需求，进一步与具体业务解耦，达到支持公司内部所有产品线的支付 第四阶段：产品化，可对公司外部使用的单独的支付产品 进一步完善安全、商户自定义操作，形成支付产品，对外提供支付产品服务（有相关牌照），这也是第三方支付渠道目前在干的事情。 一些约定## 状态统一的必要性 最核心的状态有三种： 成功、失败、处理中 。如果需求上需要显示更加精细的状态，可考虑采用子状态。 不同的支付渠道对这些状态的定义往往不同，即使同一支付渠道，对支付和代付两类接口的状态定义也经常不同。 状态统一的好处是可以更加明确的将支付渠道的（很多）状态转换成内部的统一的（三种）状态，对业务系统屏蔽不同支付渠道间的状态区别。 金额单位统一的必要性 一般情况建议使用金额单位为： 分 不同支付渠道对使用的金额单位也不统一，金额统一的好处是对业务系统屏蔽不同支付渠道间金额单位的区别。

什么叫协议？ 答： 协议顾名思义就是协商，商议后制定的合法凭证。 层对应设备与协议 ： 分层 设备 传输单元（PDU） 协议 应用层 PC SMTP，FTP，TFTP，DHCP，DNS，SNMP，HTTP，HTTPS，TELNEL 表示层 会话层 传输层 防火墙 数据段 TCP，UDP，SPX 网络层 路由器 数据包 IP，ARP，RARP，ICMP，RIP，OSPF，IGMP 数据链路层 交换机 数据帧 STP，PPP 物理层 网卡 比特流 RJ-45，EIA/TIA -568 什么叫标准？ 答： 衡量事物的准则，技术在权威测试，实践后做制定的一种标准化技术。 标准： IEEE-802局域网标准 IEEE802.3U标准：100MB/S以太网 IEEE802.3Z标准：1GB/S以太网（光纤） IEEE802.3ab标准：1GB/S以太网（双绞线） IEEE802.3ae标准：10GB/S以太网 IEEE802.3ba标准：100GB/S以太网 无线局域网标准 IEEE802.11a标准：54MB/S IEEE802.11b标准：11MB/S IEEE802.11g标准：54MB/S IEEE802.11n标准：300MB/S IEEE802.11ac标准：1GB/S 注：标准组织：OSI国际标准化组织，ANSL美国国家标准化局，ITU-T国际电信联盟，IEEE电子工程学会。 （

本文转载自 石杉的架构笔记 背景引入 首先，我们一起来看看这个问题的背景？ 前段时间有个朋友在外面面试，然后有一天找我聊说：有一个国内不错的电商公司，面试官给他出了一个场景题： 假如下单时，用分布式锁来防止库存超卖，但是是每秒上千订单的高并发场景，如何对分布式锁进行高并发优化来应对这个场景？ 他说他当时没答上来，因为没做过没什么思路。其实我当时听到这个面试题心里也觉得有点意思，因为如果是我来面试候选人的话，应该会给的范围更大一些。 比如，让面试的同学聊一聊电商高并发秒杀场景下的库存超卖解决方案，各种方案的优缺点以及实践，进而聊到分布式锁这个话题。 因为库存超卖问题是有很多种技术解决方案的，比如悲观锁，分布式锁，乐观锁，队列串行化，Redis原子操作，等等吧。 但是既然那个面试官兄弟限定死了用分布式锁来解决库存超卖，我估计就是想问一个点：在高并发场景下如何优化分布式锁的并发性能。 我觉得，面试官提问的角度还是可以接受的，因为在实际落地生产的时候，分布式锁这个东西保证了数据的准确性，但是他天然并发能力有点弱。 刚好我之前在自己项目的其他场景下，确实是做过高并发场景下的分布式锁优化方案，因此正好是借着这个朋友的面试题，把分布式锁的高并发优化思路，给大家来聊一聊。 库存超卖现象是怎么产生的？ 先来看看如果不用分布式锁，所谓的电商库存超卖是啥意思？大家看看下面的图： 这个图，其实很清晰了

线程安全性 > 当多线程访问某个类时,不管运行环境采用何种调度方式或者这些进程将如何交替执行,并且在主调代码中不需要任何的同步或者协同,这个类都能表现出正确的行为,那么这个类就是线程安全的. 原子性 > 提供互斥访问,同一时刻只有一个线程对它进行访问. Atomic包 > 位于 java.util.concurrent.atomic ,AtomicXXX : CAS、Unsafe.compareAndSwapXXX > CAS(Compare and swap) 比较和替换是设计并发算法用的的一项技术,比较和替换是用一个期望值和一个变量的当前值进行比较,如果变量的值和期望值相等,那么就用一个新值替换变量的值. 案例 > 线程安全 package com.keytech.task; import java.util.concurrent.Executor; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Semaphore; import java.util.concurrent.atomic.AtomicInteger; import java.util.concurrent.atomic.LongAdder

本篇介绍典型的基于SStable的存储。适用于与SSD一起使用。更多存储相关见： https://segmentfault.com/a/11... 。涉及到leveldb,rocksdb。基本上分布式都要单独做，重点是单机架构，数据写入，合并，ACID等功能和性能相关的。 先对性能有个直观认识： mysql写入千条/s，读万应该没问题。redis 写入 万条/s 7M/s(k+v 700bytes，双核)读是写入的1.4倍 mem 3gb 2核。这两个网上搜的，不保证正确，就看个大概吧。 SSD上 rocksdb随机和顺序的性能差不多，写要比读性能稍好。随机读写1.7万条/s 14M/s （32核）。batch_write/read下SSD单线程会好8倍。普通write只快1.2倍。 没有再一个机器上的对比。rocksdb在用SSD和batch-write/read下的读写性能还是可以的。 第一章 levelDb 架构图 读取过程 数据的读取是按照 MemTable、Immutable MemTable 以及不同层级的 SSTable 的顺序进行的，前两者都是在内存中，后面不同层级的 SSTable 都是以 *.ldb 文件的形式持久存储在磁盘上 写入过程 1.调用 MakeRoomForWrite 方法为即将进行的写入提供足够的空间； 在这个过程中，由于 memtable

点击上方 蓝色字体 ，选择“标星公众号” 优质文章，第一时间送达 作者 | IT胖 来源 | urlify.cn/BzA3ea 66套java从入门到精通实战课程分享 许多三方网站和应用可以与Jenkins交互，如Artifact仓库，基于云的存储系统和服务等. 在Jenkins中添加/配置credentials，Pipeline项目就可以使用 credentials 与三方应用交互 Credential 类型 参考：https://jenkins.io/zh/doc/book/using/using-credentials/ Jenkins可以存储以下类型的credentials: Secret text - API token之类的token (如GitHub个人访问token) Username and password - 可以为独立的字段，也可以为冒号分隔的字符串：username:password(更多信息请参照 处理 credentials) Secret file - 保存在文件中的加密内容 SSH Username with private key - SSH 公钥/私钥对 Certificate - a PKCS#12 证书文件 和可选密码 Docker Host Certificate Authentication credentials.

Osc乱弹歌单（2020）请戳（ 这里 ） 【今日歌曲】 @ 温家成 ：分享谢安琪的单曲《十二月二十二》 谢安琪的单曲《十二月二十二》 手机党少年们想听歌，请使劲儿戳（ 这里 ） @ Xiaoshiyue ：当你做了好吃的午餐，会成为你起床上班的动力 ！ 能自己做饭真好， 让别人做饭就等于把自己要害让别人掌握了。 “我大便都是三角形的……粽子真是害人不浅。” 有饭吃了， 还要有奶茶喝才是完整的一天， @ Xiaoshiyue ：转20让我喝杯奶茶甜甜嘴暖暖心 不然我就把奥特曼那啥了 让你再也见不到光 @ 小小编辑 ：只要胆子大 奥特曼休产假 还想把奥特曼那啥了！ 但是真有奥特曼么。 “现在出现了一个悖论，你是奥特曼，你还想让奥特曼休产假！这感觉像在看《原目的地》” 今天是圣诞节， 休不休假，但是要发个苹果。 @ somaGYQ ：今日话题：公司发苹果了没？ 不仅仅发苹果了， 还发了一个削苹果的。 “本是同根生，相煎何太急。” 没人送圣诞礼物的话， 就自己送给自己圣诞礼物。 @ 我想换名字 ：提前送自己的 圣诞礼物 我想想我想要什么圣诞礼物呢， “你要不是个孩子，圣诞老人可能去年这个时候就开枪把你打死了，今年圣诞老人得新冠了，你没礼物了。” @ 来域工作室 ：今日话题：平安夜和圣诞节 单身狗过什么圣诞节， 看见他们秀恩爱就生气。 “大半夜她家还灯火通明的。亮了一个晚上。哈哈哈哈哈”

CAS集群分为服务器端集群和客户端集群。 ##CAS服务器端集群## CAS服务器端集群主要解决两个问题: session同步和Ticket（票据）仓库共享。 实现环境的网络拓扑图如下： ###环境变量定义### CAS_HOME: CAS Server源码包目录(版本： 3.5.2) CATALINA_HOME: tomcat目录（版本： 7.0.42） ###配置session同步### 由于这里将CAS服务器端应用部署在tomcat上，因此session同步的配置方法和普通的tomcat session同步一样。这里给出一个例子： 在*$CATALINA_HOME/conf/server.xml*中的<Engine>节点添加如下的配置片段： <!-- lang: xml --> <Host> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="6"> <Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/> <Channel className=

2017精选索引，入选规则为： 截止至2017年12月28日文章 截止到发文，阅读1W+ 【架构必备】 《 互联网架构如何实现“高并发” 》4W+ 《 TCP接入层的负载均衡、高可用、扩展性架构设计 》2.2W+ 《 配置中心架构设计演进 》1.7W+ 《 跨公网调用的大坑与架构优化 》1.4W+ 《 DNS在架构设计中的巧用 》1.9W+ 《 消息如何在网络上安全传输 》1.2W+ 《 10W定时任务，如何高效触发 》2.9W+ 《 工作线程究竟设置为多少合适 》2.1W+ 《 URI设计原则 》1.9W+ 【一致性】 《 session一致性架构设计实践 》3.5W+ 《 MySQL双主架构一致性优化 》1.6W+ 《 库存扣多了，到底怎么整 》2.1W+ 《 再议库存扣减多种方案 》1.4W+ 《 浅谈CAS在分布式ID生成方案上的应用 》1.3W+ 《 CAS下ABA问题及优化方案 》1.1W+ 【分层架构设计】 《 互联网分层架构的本质 》2.8W+ 《 分层架构，为什么需要服务化 》2W+ 《 分层架构，是否需要业务服务层 》1.4W+ 《 分层架构，为什么需要前后端分离 》2.9W+ 《 分层架构，前后端分离的坏处 》1.8W+ 《 分层架构，为什么要引入数据库中间层 》1.8W+ 《 分层架构，APP分层架构随想 》1.4W+ 【数据库-SQL】 《