ecache

有人说，SVM是现成最好的分类器，指的是该分类器不加修改既可直接使用。同时意味着在数据上应用基本形式的SVM分类器可以得到低的错误率的结果。 SVM有很多实现，但是最流行的是实现序列最小优化SMO，通过核函数Kernel将SVM扩展到更多的数据集上 优点：泛化错误率低，计算开销不大，结果易解释 缺点：对参数调节和核函数的选择敏感，原始分类器不加修改只适合处理二类问题 适用于标称型数据和数值型数据 支持向量就是离分隔超平面最近的那些点。我们要做的是最大化支持向量到分隔面的距离 https://www.cnblogs.com/steven-yang/p/5658362.html 具体数学意义上的理解可以参考这个博客 from numpy import * from time import sleep def loadDataSet(fileName): dataMat = []; labelMat = [] fr = open(fileName) for line in fr.readlines(): lineArr = line.strip().split( ' \t ' ) dataMat.append([float(lineArr[0]), float(lineArr[ 1 ])]) labelMat.append(float(lineArr[ 2 ])) return

工程背景介绍： 我们开发了一个万能接口，用户通过这个接口中传入数据，我们拿到数据进行复杂的逻辑处理然后再将数据各种匹配展示分发等操作，处理的流程相当庞大，接口中我们只保留了接收数据和返回一个本次请求的id的操作，其余操作都是异步到其他程序中处理的。 返回id的操作是需要和数据库进行两次连接，一次读库得到最新的id 然后把id更新到数据库。 项目出现问题： 我们以为自己的程序就像上图中的那样运行，一次请求，读库，写库，返回id，其余异步处理。但是没有考虑高并发，强压力写的性能问题，在高并发下，多个接口线程同事访问数据库，这样的情况会出现并发同步的问题，当然这点我们是考虑到了 ，使用线程锁可避免数据的幻读，重复读等。可一旦这样大量的接口线程堆积，很快服务器cpu将扛不住发生宕机！ 那如果不试用线程同步锁呢，很明显不只是数据的错乱问题将发生，数据库在极大线程的访问压力下也将抗不住，cpu使用率达到85%！程序面临着瘫痪的风险。 解决方式： 1.数据库集群？ 好处：增加数据库服务器，压力随之分摊到几个服务器中，减小数据库压力 坏处：硬件成本大 数据库主从问题 哈希一致性问题 单点故障问题 2.接口服务器集群 好处：访问压力被分摊到几个服务器中 线程的堆积问题得到有效解决 坏处：硬件成本大 单点故障问题 nignx负载均衡服务器的搭建 操作复杂 以上两种方案都是增加硬件成本，加大了开发难度

1. 该说的话 每个人都应当学会独立地去思考、去寻找答案，而不是一味地伸手向他人索取所谓的标准答案。 首先，别成为“拿来主义”者，其次远离"拿来主义"的人。 2. ehcache 2.1 主要特性 快速，简单. 多种缓存策略 缓存数据有两级：内存和磁盘，因此无需担心容量问题 缓存数据会在虚拟机重启的过程中写入磁盘 可以通过RMI、可插入API等方式进行分布式缓存 具有缓存和缓存管理器的侦听接口 支持多缓存管理器实例，以及一个实例的多个缓存区域 提供Hibernate的缓存实现 2.2 和redis相比 ehcache直接在jvm虚拟机中缓存，速度快，效率高；但是缓存共享麻烦，集群分布式应用不方便。 redis是通过socket访问到缓存服务，java 框架项目案例：www.1b23.com 。效率比ecache低，比数据库要快很多. 2.3 在应用程序中的位置 3. spring boot 整合 1.搭建spring boot 项目 2. pom.xml文件中添加依赖 < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-cache </ artifactId > </ dependency > < dependency > <

工程背景介绍： 我们开发了一个万能接口，用户通过这个接口中传入数据，我们拿到数据进行复杂的逻辑处理然后再将数据各种匹配展示分发等操作，处理的流程相当庞大，接口中我们只保留了接收数据和返回一个本次请求的id的操作，其余操作都是异步到其他程序中处理的。 返回id的操作是需要和数据库进行两次连接，一次读库得到最新的id 然后把id更新到数据库。 项目出现问题： 我们以为自己的程序就像上图中的那样运行，一次请求，读库，写库，返回id，其余异步处理。但是没有考虑高并发，强压力写的性能问题，在高并发下，多个接口线程同事访问数据库，这样的情况会出现并发同步的问题，当然这点我们是考虑到了 ，使用线程锁可避免数据的幻读，重复读等。可一旦这样大量的接口线程堆积，很快服务器cpu将扛不住发生宕机！ 那如果不试用线程同步锁呢，很明显不只是数据的错乱问题将发生，数据库在极大线程的访问压力下也将抗不住，cpu使用率达到85%！程序面临着瘫痪的风险。 解决方式： 1.数据库集群？ 好处：增加数据库服务器，压力随之分摊到几个服务器中，减小数据库压力 坏处：硬件成本大 数据库主从问题 哈希一致性问题 单点故障问题 2.接口服务器集群 好处：访问压力被分摊到几个服务器中 线程的堆积问题得到有效解决 坏处：硬件成本大 单点故障问题 nignx负载均衡服务器的搭建 操作复杂 以上两种方案都是增加硬件成本，加大了开发难度