offset

EQueue架构 EQueue是一个分布式的、轻量级、高性能、具有一定可靠性，纯C#编写的消息队列，支持消费者集群消费模式。 主要包括三个部分：producer, broker, consumer。producer就是消息发送者；broker就是消息队列服务器，负责接收producer发送过来的消息，以及持久化消息；consumer就是消息消费者，consumer从broker采用拉模式到broker拉取消息进行消费，具体采用的是long polling（长轮训）的方式。这种方式的最大好处是可以让broker非常简单，不需要主动去推消息给consumer，而是只要负责持久化消息即可，这样就减轻了broker server的负担。同时，consumer由于是自己主动去拉取消息，所以消费速度可以自己控制，不会出现broker给consumer消息推的太快导致consumer来不及消费而挂掉的情况。在消息实时性方面，由于是长轮训的方式，所以消息消费的实时性也可以保证，实时性和推模型基本相当。 EQueue是面向topic的架构，和传统的MSMQ这种面向queue的方式不同。使用EQueue，我们不需要关心queue。producer发送消息时，指定的是消息的topic，而不需要指定具体发送到哪个queue。同样，consumer发送消息也是一样，订阅的是topic

ent 提供了方便的数据分页以及排序处理 limit 分页 users, err := client.User. Query(). Limit(n). All(ctx) offset 分页 users, err := client.User. Query(). Offset(10). All(ctx) order 排序 users, err := client.User.Query(). Order(ent.Asc(user.FieldName)). All(ctx) 参考资料 https://entgo.io/docs/paging/ 来源： https://www.cnblogs.com/rongfengliang/p/11677175.html

作者：陈肃 整理：周奇，Apache Flink 社区志愿者 本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎

文件/大文件上传功能实现（JS+PHP） 参考博文： 掘金-橙红年代 前端大文件上传 路漫漫 其修远 PHP + JS 实现大文件分割上传 本文是学习文件上传后的学习总结文章，从无到有实现文件上传功能，前端小白写的代码不是最优，如果有错误的地方请多多指教，如果本文对你有所帮助，深感荣幸。 近期公司的项目中，涉及到上传大文件的问题，大文件上传用普通表单上传时出现的问题是，无法断点续存，一但中途中断上传，就要重头开始，这很明显不是我们想要的，所以经过一番查询，学习了一下大文件分割上传的方法。并且使用简单的 php 做服务端处理程序实现一个功能demo，供以后回顾使用。本人也是初出茅庐的前端小白，记录下各种功能的实现总结，代码有错误的地方，请多多指正。 1.简单文件上传 普通表单上传 表单上传是我们经常使用的功能，而且使用起来也是非常简单，我们只需要声明表单内容类型为 enctype="multipart/form-data" ,表明表单上传文件的二进制数据。 <form action="index.php" method="post" enctype="multipart/form-data"> <input type="file" name="myfile" /> <input type="submit" value="上传" /> </form> 点击上传按钮

.386 .model flat,stdcall option casemap:none ;========================== ;include部分 include windows.inc include gdi32.inc include user32.inc includelib user32.lib includelib gdi32.lib include kernel32.inc includelib kernel32.lib ;=========================== ;未初始化数据段 .data? hInstance dd ? ;主程序句柄 hManinHwnd dd ? ;主窗口句柄 ;常量段 .const szContent db "this is first window",0 szWindowClass db "New_Window",0 szTitle db "My_First_Window",0 szButton db "Button",0 szButtonTitle db "&Cancel",0 ;已初始化的数据段 .data szMsgText db 1024 dup(?) szFrmatText db "ebx:%0.8X",0 ;代码段 .code _WindowCallbackProc proc uses ebx

在公司干活一般使用sqlserver数据库。rownumber分页贼好用。 但是晚上下班搞自己的事情就不用sqlserver了。原因就是自己的渣渣1核2g的小服务器完全扛不住sqlserver那么大的大块头，于是就使用Mysql数据库。 一般使用MySQL分页都是使用limit，我也这么使用的。 今天晚上打开一个服务器上的小网站，顺便点几下看看有没有问题，不小心点到了最后一页，卡了我近10秒才反应过来。我数据库就7w多条数据。虽说服务器垃圾也不至于卡这么久吧。。 然后把分页的sql找出来，去数据库手动执行。发现确实越往后翻页越慢，翻到四万多条的时候，都好几秒才响应了。这完全无法接受啊。难怪最近网站的搜索引擎权重又降低了。。5555 分页sql如下 select id ,title,time from table where type = ‘xxx’ ORDER BY createtime limit 10 offset 45000 因为Id是主键，我尝试去掉了title和time字段，马上就秒开了。 查看数据库执行计划，索引是已经命中了。但是为什么还是很卡呢？ 查阅了不少资料，得出两个结论 1.服务器实在是太垃圾了。 2.limit x offset x 分页确实有性能问题，据说阿里的dba都不太建议offset太多。。。 解决方案： 既然都无法使用offset，那就曲线救国。

1. RSA 算法介绍 RSA 算法是一种非对称算法，即是加密的密码和解密的密码是不一致的。因此对 RSA 的加密和加密的密码分为公钥和私钥。根据 RSA 的算法介绍，只要密钥的长度足够长，现在没有任何方法可以破解。而且这个算法的专利已经在 2000 年 9 月 21 日失效，因此应该是可以任意使用的。 密钥获取： 选用 PKCS#8 生成密钥，选 PKCS#1 可能会导致解密失败 http://web.chacuo.net/netrsakeypair 1. javaweb 使用 RSA 1.1. 前端加密 要在前端加密密码，就要使用到jsencrypt 的 js 1.1.1. jsencrypt 下载 官网： http://travistidwell.com/jsencrypt/ github: https://github.com/travist/jsencrypt/releases 在 bin 目录下面可以找到相关 js ： 1.1.2. 代码示例 1 //RSA加密 2 function encryptRequest(reqUrl, data) { 3 var publicKey = "****"; 4 var encrypt = new JSEncrypt(); 5 encrypt.setPublicKey(publicKey); 6 // ajax请求发送的数据对象 7

对于document.compatMode，很多朋友可能都根我一样很少接触，知道他的存在却不清楚他的用途。今天在ext中看到 document.compatMode的使用，感觉这个对于我们开发兼容性的web页面还是很有帮助，我们都知道，IE对盒模型的渲染在 Standards Mode和Quirks Mode是有很大差别的，在Standards Mode下对于盒模型的解释和其他的标准浏览器是一样，但在Quirks Mode模式下则有很大差别，而在不声明Doctype的情况下，IE默认又是Quirks Mode。所以为兼容性考虑，我们可能需要获取当前的文档渲染方式。 document.compatMode正好派上用场，它有两种可能的返回值：BackCompat和CSS1Compat，对其解释如下： BackCompat Standards-compliant mode is not switched on. (Quirks Mode) CSS1Compat Standards-compliant mode is switched on. (Standards Mode) 在实际的项目中，我们还需要在获取浏览是否IE，这样就可以得到IE的渲染模式了。在Ext中的代码：isBorderBox=isIE&&!isStrict。 当文档有了标准声明时， document.compatMode

In java.util.Date : * In all methods of class <code>Date</code> that accept or return * year, month, date, hours, minutes, and seconds values, the * following representations are used: * <ul> * <li>A year <i>y</i> is represented by the integer * <i>y</i><code>-1900</code>. Of course, in Java 1.1, the getYear() method and the like were deprecated in favor of java.util.Calendar , which still has this weird deprecation note: int getYear() Deprecated. As of JDK version 1.1, replaced by Calendar.get(Calendar.YEAR) - 1900. setYear(int year) Deprecated. As of JDK version 1.1, replaced by Calendar.set