Oracle has two products that implement Java Platform Standard Edition (Java SE) 8: Java SE Development Kit (JDK) 8 and Java SE Runtime Environment (JRE) 8. JDK 8 is a superset of JRE 8, and contains everything that is in JRE 8, plus tools such as the compilers and debuggers necessary for developing applets and applications. JRE 8 provides the libraries, the Java Virtual Machine (JVM), and other components to run applets and applications written in the Java programming language. Note that the JRE includes components not required […]
View Details并发队列的选择 Java的并发包提供了三个常用的并发队列实现，分别是：ArrayBlockingQueue、ConcurrentLinkedQueue 和 LinkedBlockingQueue 。 ArrayBlockingQueue是**初始容量固定**的阻塞队列，我们可以用来作为数据库模块成功竞拍的队列，比如有10个商品，那么我们就设定一个10大小的数组队列。 ConcurrentLinkedQueue使用的是CAS原语无锁队列实现，是一个异步队列，入队的速度很快，出队进行了加锁，性能稍慢。 LinkedBlockingQueue也是阻塞的队列，入队和出队都用了加锁，当队空的时候线程会暂时阻塞。 在请求预处理阶段，由于我们的系统入队需求要远大于出队需求，一般不会出现队空的情况，所以我们可以选择ConcurrentLinkedQueue来作为我们的请求队列实现 1. 请求接口的合理设计 一个秒杀或者抢购页面，通常分为2个部分，一个是静态的HTML等内容，另一个就是参与秒杀的Web后台请求接口。 通常静态HTML等内容，是通过CDN的部署，一般压力不大，核心瓶颈实际上在后台请求接口上。这个后端接口，必须能够支持高并发请求，同时，非常重要的一点，必须尽可能“快”，在最短的时间里返回用户的请求结果。为了实现尽可能快这一点，接口的后端存储使用内存级别的操作会更好一点。仍然直接面向MySQL之类的存储是不合适的，如果有这种复杂业务的需求，都建议采用异步写入。 当然，也有一些秒杀和抢购采用“滞后反馈”，就是说秒杀当下不知道结果，一段时间后才可以从页面中看到用户是否秒杀成功。但是，这种属于“偷懒”行为，同时给用户的体验也不好，容易被用户认为是“暗箱操作”。 高并发下的数据安全 我们知道在多线程写入同一个文件的时候，会存现“线程安全”的问题（多个线程同时运行同一段代码，如果每次运行结果和单线程运行的结果是一样的，结果和预期相同，就是线程安全的）。如果是MySQL数据库，可以使用它自带的锁机制很好的解决问题，但是，在大规模并发的场景中，是不推荐使用MySQL的。秒杀和抢购的场景中，还有另外一个问题，就是“超发”，如果在这方面控制不慎，会产生发送过多的情况。我们也曾经听说过，某些电商搞抢购活动，买家成功拍下后，商家却不承认订单有效，拒绝发货。这里的问题，也许并不一定是商家奸诈，而是系统技术层面存在超发风险导致的。 1. 超发的原因 假设某个抢购场景中，我们一共只有100个商品，在最后一刻，我们已经消耗了99个商品，仅剩最后一个。这个时候，系统发来多个并发请求，这批请求读取到的商品余量都是99个，然后都通过了这一个余量判断，最终导致超发。（同文章前面说的场景） 在上面的这个图中，就导致了并发用户B也“抢购成功”，多让一个人获得了商品。这种场景，在高并发的情况下非常容易出现。 2. 悲观锁思路 解决线程安全的思路很多，可以从“悲观锁”的方向开始讨论。 悲观锁，也就是在修改数据的时候，采用锁定状态，排斥外部请求的修改。遇到加锁的状态，就必须等待。 虽然上述的方案的确解决了线程安全的问题，但是，别忘记，我们的场景是“高并发”。也就是说，会很多这样的修改请求，每个请求都需要等待“锁”，某些线程可能永远都没有机会抢到这个“锁”，这种请求就会死在那里。同时，这种请求会很多，瞬间增大系统的平均响应时间，结果是可用连接数被耗尽，系统陷入异常。 3. FIFO队列思路 那好，那么我们稍微修改一下上面的场景，我们直接将请求放入队列中的，采用FIFO（First Input First Output，先进先出），这样的话，我们就不会导致某些请求永远获取不到锁。看到这里，是不是有点强行将多线程变成单线程的感觉哈。 然后，我们现在解决了锁的问题，全部请求采用“先进先出”的队列方式来处理。那么新的问题来了，高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态。或者设计一个极大的内存队列，也是一种方案，但是，系统处理完一个队列内请求的速度根本无法和疯狂涌入队列中的数目相比。也就是说，队列内的请求会越积累越多，最终Web系统平均响应时候还是会大幅下降，系统还是陷入异常。 4. 乐观锁思路 这个时候，我们就可以讨论一下“乐观锁”的思路了。乐观锁，是相对于“悲观锁”采用更为宽松的加锁机制，大都是采用带版本号（Version）更新。实现就是，这个数据所有请求都有资格去修改，但会获得一个该数据的版本号，只有版本号符合的才能更新成功，其他的返回抢购失败。这样的话，我们就不需要考虑队列的问题，不过，它会增大CPU的计算开销。但是，综合来说，这是一个比较好的解决方案。 有很多软件和服务都“乐观锁”功能的支持，例如Redis中的watch就是其中之一。通过这个实现，我们保证了数据的安全。 from:https://my.oschina.net/momisabuilder/blog/2992962
View DetailsC#与C的区别 C#通常不使用指针。 可以在一个方法里的任何地方声明变量，不必把声明语句放在方法的顶端。 使用一个对象前，不一定要声明它，可以在用到的时候再定义。 C#对结构体类型的定义有些不同，它根本不支持联合类型。 C#有枚举类型，允许一系列被命名的量（如颜色或一周里的各天）赋值为连续的数值，但语法有些不同。 C#没有位域，也就是说，变量至少要占用一个字节的存储空间。 C#不支持长参数列表。必须针对参数值和类型定义一个方法。然而，C#语句允许函数的最后一个参数为可变参数数组。 C#引入了代理和索引器的思想，这些在其他流行的语言中是没有的。 C#与Java的区别 C#与Java关系密切，由于C#是在Java之后设计出来的，它吸收了Java的大部分精华。但两者还是有一些细微差别。 许多系统对象方法都有相同的方法名，只是在大小写形式上有区别。 C#不提供throws关键字，该关键字使编译器检查你是否捕获了一个方法抛出的异常。 C#对于布局管理器有更多的限制。因为它是以Windows系统为中心的，大多数时候采取的是图形元素的绝对位置。 C#允许运算符重载。 C#引进了代理和索引器。 C#有枚举类型。 C#有不安全模式，在这种模式下可以使用指针。 必须专门声明一个方法能被覆盖及一个方法能覆盖另一个方法。 不能通过声明来区别继承和接口实现，它们的声明方式是一样的。 switch语句允许使用字符串变量。如果变量没有被匹配，必须有一个默认情况，否则会出现错误。break语句是必需的。 布尔变量类型在C#中拼为“bool”，在Java中拼为“boolean”。 摘自《C#设计模式》
View Details解决问题前，首先确定[FormBodyAttribute]的定义以及功能范围，相关资料： https://docs.microsoft.com/en-us/aspnet/web-api/overview/formats-and-model-binding/parameter-binding-in-aspnet-web-api 其实文中已经讲得足够详细，一般来讲FormUri获取参数不会存在什么疑惑，但在不了解规则的情况下如何设置和获取FormBody标识的值却有些迷惑：我到底该怎么传递参数api才能够获取到参数？很多文章给出的解决方案是利用="json string"这样的方式进行提交，但实在太别扭了。这样的代码写出去会被打吧…所以，到底该怎么请求呢？ 如果你仔细阅读过文章，相信你应该注意到了这一段： When a parameter has [FromBody], Web API uses the Content-Type header to select a formatter. 意思是对于被标记为FromBody的parameter，WebApi默认会根据Content-Type中选择格式化方法。由于Web程序中常常使用JSON方式传递数据，所以这里只针对Content-Type="application/json"的请求进行分析。接着看下一句： In this example, the content type is "application/json" and the request body is a raw JSON string (not a JSON object). 其实到这里已经给出解决方案了，即Content-Type="application/json"的请求都需要将参数转换为JSON string，而非JSON Object. 接下来代码说话的时间到了： 1)创建一个复杂对象的实体类DataParameter： 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 29 30 31 32 33 34 35 36 37 [Serializable] public class DataParameter { public DataParameter() […]
View Details继续接着上文 ASP.NET MVC学习系列(一)-WebAPI初探 来看看对于一般前台页面发起的get和post请求，我们在Web API中要如何来处理。 这里我使用Jquery 来发起异步请求实现数据调用。 继续使用上一文章中的示例，添加一个index.html页面，添加对jquery的引用。 一、无参数Get请求 一般的get请求我们可以使用jquery提供的$.get() 或者$.ajax({type:"get"}) 来实现： 请求的后台Action方法仍为上篇文章中的GetUser() : 也可以用$.ajax({type:"get"}) 方式，正确的获得了返回数据： 二、传递一个参数的Get请求 通常我们需要传递参数只需要指定ajax方法的data属性即可： data:{"name":"赵大宝"} 后台正确的返回数据： 三、传递两个或多个参数的Get请求 按照上面的方法，对于多个参数我们可以很容易就写出来： data:{"name":"赵大宝","age":12} 后台正确的返回数据： 四、无参数的Post请求 我们可以使用$.post() 或$.ajax({type:"post"}) 来发起post请求： 后台正确的返回了数据： 五、传递一个参数的Post请求： 首先这里需要提醒大家一下，我们在修改完后台代码后，如果没有重新生成项目，那么在请求时就会报错：“未找到与请求***匹配的HTTP资源” ： 所以，我们只要我们修改了后台代码，就一定要重新生成一下： 不过，当我们重新生成项目，再次发送请求，看到的仍然是404错误，再次检查一番代码，也没有发现是哪里的问题。 事实上，ASP.NET Web API能够正确的识别我们的UserController控制器处理Post /api/user ，但却不能找到一个可以接受的方法来处理请求。 也就是说，Web API接收到的请求能够找到User控制器，但在该控制器中找不到名称为Def 的这个Action。 那我们要怎么来解决呢？ 通过搜索MSDN上Web API官网中的说明，我们可以找到下面的一段介绍： 即在Action 方法中我们需要使用 [FromBody] 属性标签来标明属性。 修改后，再次发送请求，我们可以看到，Status Code 为200，请求发送成功。 可以看到，在post请求中，方法的参数必须要用 [FromBody] 属性来修饰才可以， [FromBody] 就告诉Web API 要从post请求体重去获取参数的值。 但让我们诧异的却是，后台返回的数据中name的值为空。 通过调试，我们可以看到，后台Action 中接收到的name值为null。 通过上面的测试我就也能够猜测到，Web API 要求请求传递的 [FromBody] 参数，肯定是有一个特定的格式，才能被正确的获取到。而这种特定的格式并不是我们常见的 key=value 的键值对形式。Web API 的模型绑定器希望找到 [FromBody] 里没有键名的值，也就是说， 不是 key=value ，而是 =value 。 现在，咱们把data中的key设置为空，然后再次发送请求： 测试可见，后台正确的接收到了数据: 六、传递两个参数的Post请求 按理说，一个参数的请求实现了，那么传递两个或者多个参数也就很顺利了，对于两个参数的后台接收方法，我们可能会这样来写: 但事实证明，这样是错误的。 那到底两个或者多个参数我们要怎样来定义呢？ […]
View Details今天在来一发 webapi的一个知识点 相信用过webapi的对这个错误 已经看在眼里 痛在心里了把 我百度也搜了一下 看了一下 然后发现他们的解决办法 并没有什么软用。 然后想起来当时上学的时候 老师讲过这个知识点 然后又找到了 老师 0.0 当时老师写的一个笔记。我直接上截图了。 在webapiConfig里面加一行代码 就好。 然后 又是我们熟悉而可爱的json了。 代码是 GlobalConfiguration.Configuration.Formatters.XmlFormatter.SupportedMediaTypes.Clear(); from:https://www.cnblogs.com/uglyman/p/6890706.html?utm_source=itdadao&utm_medium=referral
View Details数据结构 队列 集合 链表、数组 字典、关联数组 栈 树 二叉树 完全二叉树 平衡二叉树 二叉查找树（BST） 红黑树 B，B+，B*树 LSM 树 BitSet 常用算法 排序、查找算法 选择排序 冒泡排序 插入排序 快速排序 归并排序 希尔排序 堆排序 计数排序 桶排序 基数排序 二分查找 Java 中的排序工具 布隆过滤器 字符串比较 KMP 算法 深度优先、广度优先 贪心算法 回溯算法 剪枝算法 动态规划 朴素贝叶斯 推荐算法 最小生成树算法 最短路径算法 并发 Java 并发 多线程 线程安全 一致性、事务 事务 ACID 特性 事务的隔离级别 MVCC 锁 Java中的锁和同步类 公平锁 & 非公平锁 悲观锁 乐观锁 & CAS ABA 问题 CopyOnWrite容器 RingBuffer 可重入锁 & 不可重入锁 互斥锁 & 共享锁 死锁 操作系统 计算机原理 CPU 多级缓存 进程 线程 协程 Linux 设计模式 设计模式的六大原则 23种常见设计模式 应用场景 单例模式 […]
View Details最近在工作中遇到一个需求，需要使用 nginx 反向代理websocket，经过查找一番资料，目前已经测试通过，所以这篇文章主要给大家介绍了Nginx反向代理WebSocket配置的相关资料，需要的朋友可以参考借鉴，下面来一起看看吧。 实现方案 采用目前比较成熟的WebSocket技术，WebSocket协议为创建客户端和服务器端需要实时双向通讯的webapp提供了一个选择。其为HTML5的一部分，WebSocket相较于原来开发这类app的方法来说，其能使开发更加地简单。大部分现在的浏览器都支持WebSocket，比如Firefox，IE，Chrome，Safari，Opera，并且越来越多的服务器框架现在也同样支持WebSocket。 WebSocket集群 在实际的生产环境中，要求多个WebSocket服务器必须具有高性能和高可用，那么WebSocket协议就需要一个负载均衡层，NGINX从1.3开始支持WebSocket，其可以作为一个反向代理和为WebSocket程序做负载均衡。 Nginx配置 注：看官方文档说 Nginx 在 1.3 以后的版本才支持 websocket 反向代理，所以要想使用支持 websocket 的功能，必须升级到 1.3 以后的版本 NGINX通过允许一个在客户端和后端服务器之间建立的隧道来支持WebSocket。为了NGINX发送来至于客户端Upgrade请求到后端服务器，Upgrade和Connection头部必须被设置明确。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
upstream wsbackend { server 127.0.0.1:8080; server 127.0.0.1:8081; } server { listen 80; server_name ws.52itstyle.com; location / { proxy_pass http://wsbackend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } |
|
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 29 30 |
<strong>前端配置：</strong> $(function(){ socket.init(); }); //Nginx反向代理实现websocket var basePath = "ws://ws.52itstyle.com//acts_competition/"; socket = { webSocket : "", init : function() { if ('WebSocket' in window) { webSocket = new WebSocket(basePath+'webSocketServer'); } else if ('MozWebSocket' in window) { webSocket = new MozWebSocket(basePath+"webSocketServer"); } else { webSocket = new SockJS(basePath+"sockjs/webSocketServer"); } webSocket.onerror = function(event) { //alert("websockt连接发生错误，请刷新页面重试!") }; webSocket.onopen = function(event) { }; webSocket.onmessage = function(event) { }; }, sendData : function(data) { webSocket.send(data); }, } |
最后，重启下Nginx即可。 反向代理服务器在支持WebSocket时面临的挑战 WebSocket是端对端的，所以当一个代理服务器从客户端拦截一个Upgrade请求，它需要去发送它自己的Upgrade请求到后端服务器，也包括合适的头。 因为WebSocket是一个长连接，不像HTTP那样是典型的短连接，所以反向代理服务器需要允许连接保持着打开，而不是在它们看起来空闲时就将它们关闭。 总结 以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作能带来一定的帮助，如果有疑问大家可以留言交流，谢谢大家对脚本之家的支持。 原文链接：http://blog.52itstyle.com/archives/736/
View DetailsWEBAPI中的Request是HttpRequestMessage类型，不能像Web传统那样有querystring和from 方法接收参数，而传统的HttpReqest的基类是HttpReqestBase 所以这里我们就直接使用(HttpContextBase)Request.Properties["MS_HttpContext"]
|
1 2 3 4 5 6 |
public void Post([FromBody]string value) { HttpContextBase context = (HttpContextBase)Request.Properties["MS_HttpContext"];//获取传统context HttpRequestBase request = context.Request;//定义传统request对象 string name = request.Form["name"]; } |
1.获取遍历路由参数
|
1 2 3 4 5 6 7 8 9 |
//获取路由参数 IDictionary<string, object> dic = this.RequestContext.RouteData.Values; StringBuilder builder = new StringBuilder(); foreach (var item in dic) { builder.AppendFormat("key:{0},value:{1}", item.Key, item.Value); builder.AppendLine(); } return builder.ToString(); |
2.遍历表单参数
|
1 2 3 4 5 6 7 8 9 10 |
////获取表单参数 HttpContextBase context = (HttpContextBase)Request.Properties["MS_HttpContext"];//获取传统context HttpRequestBase request = context.Request;//定义传统request对象 StringBuilder builder = new StringBuilder(); foreach (string item in request.Form.Keys) { builder.AppendFormat("key:{0},value:{1}", item, request.Form[item]); builder.AppendLine(); } return builder.ToString(); |
from:http://www.cnblogs.com/tianma3798/p/5089890.html
View Details