offset

Vector3 MyScreenPointToWorldPoint(Vector3 ScreenPoint, Transform target) { 　　 //得到物体在主相机的某个方向 　　Vector3 dir = (target.position - Camera.main.transform.position); 　　//计算投影 　　Vector3 norVec = Vector3.Project(dir, Camera.main.transform.forward); 　　return Camera.main.ViewportToWorldPoint( 　　　　new Vector3( 　　　　　　ScreenPoint.x/Screen.width, 　　　　　　ScreenPoint.y/Screen.height, 　　　　　　norVec.magnitude 　　　　) 　　); } 　　Vector3 startPos;　　 　　Vector3 endPos; 　　Vector3 offset; private void OnMouseDown() { 　　startPos = MyScreenPointToWorldPoint(Input.mousePosition, transform); } private void OnMouseDrag() { 　

1.DAO层使用泛型类，主要是定义一些通用的增删改查，然后其他DAO的类都来继承该类，通过构造方法将class对象传给该泛型类 定义泛型接口 package sanitation.dao;import java.util.List;/** * * @param <T> */public interface GenericDAO <T>{ /** * 通过ID获得实体对象 * * @param id实体对象的标识符 * @return 该主键值对应的实体对象 */ T findById(int id); /** * 将实体对象持久化 * * @param entity 需要进行持久化操作的实体对象 * @return 持久化的实体对象 */ T makePersitent(T entity); /** * 将实体变为瞬态 * * @param entity需要转变为瞬态的实体对象 */ void makeTransient(T entity); /** * 将一系列的实体变为瞬态，使用本地sql * * @param hql */ void makeTransientByIds(String sql); /** * * 使用hql语句进行分页操作 * * @param hql * @param offset 第一条记录索引 * @param pageSize 每页需要显示的记录数 *

学 无 止 境 ， 与 君 共 勉 。 介绍 按照官网的说法，Redis位图Bitmaps不是实际的数据类型，而是在字符串类型上定义的一组 面向位的操作 。在Redis中字符串限制最大为 512MB ，所以位图中最大可以设置 2^32 个不同的位（ 42.9亿个 ）。图位的最小单位是比特(bit)，每个bit的值只能是0或1。 位图的存储大小计算： （maxOffset / 8 / 1024 / 1024）MB。其中maxOffset为位图的最大位数 基本用法 SETBIT key offset value 设置指定key的值在offset处的bit值，offset从0开始。返回值为在offset处原来的bit值 # 通过位操作将 h 改成 i 127.0.0.1:6379> SET h h # 二进制为 01101000 OK 127.0.0.1:6379> SETBIT h 7 1 # 将最后一位改成1 => 01101001 (integer) 0 127.0.0.1:6379> GET h "i" GETBIT key offset 获取指定key的值在offset处的bit值，offset从0开始。如果offset超出了当前位图的范围，则返回0。 127.0.0.1:6379> set i i # 二进制为 01101001 OK 127.0.0.1:6379>

背景 系统采用Spring Cloud Stream框架集成Kafka来实现异步消息。 问题 客户端消费某个topic消息出错时，会连续输出这个消息内容3次，同时没有提交offset。当有大量消息出错时，topic出现消息积压。 分析 首先，我们知道实现异步消息的系统架构一般包含3个部分：生产者Producer、消息中间件Broker、消费者Consumer。其中， 消息中间件Broker，是指二进制安装包安装的单机Kafka或利用zookeeper组成的Kafka集群或者阿里云Kafka集群。 生产者Produer和消费者Consumer，是指基于kafka-clients包，实现我们业务逻辑的消息生产者及消费者。 而spring-cloud-stream，是一个高度可扩展的基于事件驱动的框架，在系统中属于更高层级。系统层级：业务代码 -> spring-cloud-stream -> spring-integration -> spring-messaging -> spring-kafka -> kafka-clients -> kafka broker。 其次，我们需要了解几个关键点： Kafka Broker支持Consumer提交offset，仅此而已。offset自动提交及手动提交，是由Kafka Consumer实现的。 不要误以为offset自动提交

Flink学习-DataStream-KafkaConnector 摘要 本文主要介绍Flink1.9中的DataStream之KafkaConnector，大部分内容翻译、整理自官网。以后有实际demo会更新。 可参考 kafka-connector 如果关注Table API & SQL中的KafkaConnector，请参考 Flink学习3-API介绍-SQL 1 Maven依赖 FlinkKafkaConnector版本很多，如果使用的Kafka版本0.11以前的版本就必须仔细核对使用的包的版本，而在0.11开始可以使用统一KafkaConnectorApi，会使用该Flink版本发布时的最新Kafka版本，用法如下： < dependency > < groupId > org.apache.flink </ groupId > < artifactId > flink-connector-kafka_2.11 </ artifactId > < version > 1.11-SNAPSHOT </ version > </ dependency > 2 KafkaConsumer 2.1 KafkaConsumer构建 创建一个KafkaConsumer例子： // 1. get streaming runtime val env :

1、为什么要使用消息队列? 主要有三个原因: 解耦、异步、削峰 (1)解耦 传统模式: 传统模式的 缺点 ： 系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！ 中间件模式: 中间件模式的的 优点 ： 将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。 (2)异步 传统模式: 传统模式的 缺点 ： 一些非必要的业务逻辑以同步的方式运行，太耗费时间。 中间件模式: 中间件模式的的 优点 ： 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度 (3)削峰 传统模式 传统模式的 缺点 ： 并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常 中间件模式: 中间件模式的的 优点 ： 系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。 2、使用了消息队列会有什么缺点? 分析 :一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。 要记住，不要给公司挖坑！ 回答 :回答也很容易，从以下两个个角度来答 系统可用性降低 :你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去

目录： 1.offset系列 * 在style标签中设置的css样式属性，不能使用如下方法: ele.style.width ele.style.height * 以后获取元素的宽和高，使用如下方法 ele.offsetWidth;//获取宽(包含边框) ele.offsetHeight;//获取高(包含边框) * 获取元素距离左边(上)的距离 ele.offsetLeft; ele.offsetTop; * ele.offsetLeft的值与什么有关？ - 没有脱离文档流 offsetLeft=父元素的margin+父元素的padding+父元素的border+自己的margin offsetLeft=自己的left+自己的margin 2.直接通过document获取元素 * 获取body var ele = document.body;//返回body元素 * 获取title document.title;//获取title标签中的文本 document.title="重新赋值"; * document.documentElement;//获取html标签 3.案例：图片跟着鼠标飞 　　存在兼容问题，IE不起作用 <!DOCTYPE html> <html> <head> <title></title> </head> <body> <img src="a.jpg"

USE master GO --创建数据库 CREATE DATABASE test GO USE [test] GO --创建表 CREATE TABLE [dbo].[aa]( [id] [int] IDENTITY(1,1) NOT NULL, [NAME] [nvarchar](200) NULL ) ON [PRIMARY] GO --插入测试数据 INSERT [dbo].[aa] ( [NAME] ) SELECT '你好' GO --删除数据 Delete from aa Go --验证数据是否已经删除 Select * from aa Go 上面是创建数据库，表，添加数据，删除数据 下面写存储过程； --------------------------开始存储过程----------------------------------------- CREATE PROCEDURE Recover_Deleted_Data_Proc @Database_Name NVARCHAR(MAX) , @SchemaName_n_TableName NVARCHAR(MAX) , @Date_From DATETIME = '1900/01/01' , @Date_To DATETIME = '9999/12/31' AS DECLARE @RowLogContents

数据丢失是一件非常严重的事情事，针对数据丢失的问题我们需要有明确的思路来确定问题所在，针对这段时间的总结，我个人面对kafka 数据丢失问题的解决思路如下： 是否真正的存在数据丢失问题，比如有很多时候可能是其他同事操作了测试环境，所以首先确保数据没有第三方干扰。 理清你的业务流程，数据流向，数据到底是在什么地方丢失的数据，在kafka 之前的环节或者kafka之后的流程丢失？比如kafka的数据是由flume提供的，也许是flume丢失了数据，kafka 自然就没有这一部分数据。 如何发现有数据丢失，又是如何验证的。从业务角度考虑，例如：教育行业，每年高考后数据量巨大，但是却反常的比高考前还少，或者源端数据量和目的端数据量不符 定位数据是否在kafka之前就已经丢失还事消费端丢失数据的 kafka支持数据的重新回放功能(换个消费group)，清空目的端所有数据，重新消费。 如果是在消费端丢失数据，那么多次消费结果完全一模一样的几率很低。 如果是在写入端丢失数据，那么每次结果应该完全一样(在写入端没有问题的前提下)。 kafka环节丢失数据，常见的kafka环节丢失数据的原因有： 如果auto.commit.enable=true，当consumer fetch了一些数据但还没有完全处理掉的时候，刚好到commit interval出发了提交offset操作，接着consumer